¿Qué es el TTFB?

El Time to First Byte mide cuánto pasa entre que el navegador pide una página y recibe el primer byte de la respuesta. No es el tiempo de carga: cuando ese primer byte llega, todavía no se ve nada en pantalla. Es el momento en que el servidor deja de pensar y empieza a hablar.

web.dev fija como referencia 800 milisegundos para un valor bueno y 1.800 como límite de lo aceptable. A diferencia de las Core Web Vitals, el TTFB no es una métrica de evaluación por sí misma; es un diagnóstico previo que explica buena parte de lo que ocurre después.

El malentendido más extendido es tomarlo por «el tiempo del servidor». Dentro del TTFB caben, en este orden: las redirecciones que haya, el arranque del service worker si existe, la búsqueda DNS, la conexión TCP, la negociación TLS, el envío de la petición y por fin el trabajo del servidor. En muchos sitios lentos, el backend es la etapa más rápida de todas.

Esa composición explica por qué dos páginas del mismo servidor pueden dar valores muy distintos. Una que se pide directamente arranca en frío una sola vez; otra a la que se llega desde un enlace antiguo con redirección 301 repite media cadena antes de empezar.

Conviene distinguirlo de dos parientes cercanos que suelen confundirse con él. El tiempo de respuesta del servidor es solo la última etapa del TTFB; la latencia de red es solo una de las intermedias. El TTFB los engloba a ambos y a todo lo demás que ocurre antes del primer byte, y esa es precisamente su utilidad: es la única medida que abarca el camino entero.

Para una tienda de e-commerce con catálogo grande esa distinción tiene consecuencias de presupuesto. Cambiar a un alojamiento más caro corrige la última etapa; si el tiempo se iba en resolver DNS de un proveedor lento o en una cadena de saltos heredada, el dinero no compra nada.

Una redirección no añade «un paso más». Añade toda la cadena previa otra vez, y con frecuencia contra un dominio distinto, lo que obliga a resolver DNS y a negociar TLS desde cero.

El caso clásico es el enlace antiguo que apunta a http:// sin www: el navegador salta a la versión con HTTPS, de ahí a la que lleva www, y solo entonces recibe la página. Tres cadenas completas para una sola visita, y todas ocurren antes de que el usuario vea un solo píxel.

De ahí sale una regla práctica que vale para cualquier trabajo de enlazado: enlazar siempre al destino final, tanto en el enlazado interno como en las campañas. Un parámetro de seguimiento mal puesto que provoque un salto extra multiplica el coste en cada clic pagado.

Los redireccionamientos también consumen presupuesto de rastreo: cada salto es una petición que el crawler tiene que hacer para llegar al mismo sitio. En una web grande eso compite con las páginas que sí querríamos que revisara.

Las cadenas de redirección crecen solas y casi nunca por una decisión. Se acumulan con cada migración, cada cambio de estructura de URL, cada campaña que estrenó una dirección corta. Nadie las borra porque cada una funciona; el coste no se ve en ninguna pantalla y solo aparece sumado en el TTFB.

Revisarlas es de las tareas más agradecidas de una auditoría porque el arreglo es definitivo: una vez que los enlaces apuntan al destino final, el problema no vuelve. Y beneficia a la vez a la velocidad, al presupuesto de rastreo y al enlazado interno, tres cosas que rara vez mejoran con un solo cambio.

El primer paso es separar las etapas, porque las medidas son distintas para cada una. El panel de red del navegador desglosa el tiempo en espera de DNS, conexión, TLS y espera de respuesta, y con eso se sabe si el problema está antes o dentro del servidor.

Si domina la espera de respuesta, el trabajo está en el backend: consultas de base de datos sin índice, plantillas que se generan en cada visita, llamadas a servicios externos dentro del ciclo de la petición. La caché de página suele resolver el caso completo, porque convierte un cálculo en una lectura.

Si domina la conexión, el problema es la distancia. Un servidor en Fráncfort atiende a un visitante de Santiago con un retardo físico que ninguna optimización de código elimina; ahí la respuesta es una red de distribución de contenidos, que entrega desde un nodo cercano.

Si hay redirecciones, se quitan antes que nada, porque son la única etapa que se puede eliminar por completo en lugar de acelerar. Después conviene comprobar en Search Console si los datos de campo acompañan, recordando que tardan semanas en moverse.

Hay una medida que se pasa por alto y cuesta poco: comprobar que la caché realmente se aplica donde llega la gente. Muchas configuraciones excluyen automáticamente cualquier URL con parámetros, y justo esas son las que reciben el tráfico de campañas, con sus etiquetas de seguimiento puestas por Google Tag Manager.

El resultado es una web que parece rápida en las pruebas y lenta para quien llega desde un anuncio, que suele ser el visitante más caro. Merece la pena medirlo con la URL completa, parámetros incluidos, y no con la versión limpia que uno escribe a mano.

El TTFB es el primero de los cuatro tramos en que se descompone el LCP. Todo lo que se tarde aquí se arrastra entero hasta allí: si el primer byte llega al segundo, quedan 1,5 segundos para descargar y dibujar la imagen principal si se quiere entrar en el tramo bueno.

Por eso un TTFB alto es la explicación más frecuente de un LCP que no baja por más que se optimicen las imágenes. Cambiar el formato del archivo no sirve de nada si el navegador aún no ha recibido el HTML que lo menciona.

Con el INP la relación es indirecta pero real: un servidor lento suele venir acompañado de mucho JavaScript que compensa en el cliente lo que no se resolvió en el servidor, y eso ocupa el hilo principal justo cuando el usuario empieza a interactuar.

La consecuencia práctica para una auditoría de SEO técnico es de orden: mirar el TTFB antes que el resto. Es la única métrica de esta familia cuya mejora arrastra automáticamente a las demás.

Esa relación explica también por qué el TTFB aparece en discusiones sobre presupuesto de rastreo. Cada página que el crawler pide cuesta tiempo de servidor, y un TTFB alto reduce cuántas páginas alcanza a revisar en una sesión. En un sitio de miles de URLs eso decide qué se queda sin indexar durante semanas.

Y hay un efecto de segundo orden que rara vez se menciona: un servidor lento invita a compensar en el navegador. Se añade JavaScript para que la página «parezca» rápida, y ese código termina compitiendo por el hilo principal justo cuando el usuario quiere interactuar, lo que empeora el INP. La lentitud del servidor se paga dos veces.

• Tomar el TTFB por «el tiempo del servidor» y cambiar de alojamiento cuando el problema era una cadena de redirecciones.
• Medir desde la oficina y concluir que va bien: la distancia al servidor cambia el resultado más que casi cualquier optimización.
• Activar una caché y no comprobar que realmente se aplica a las páginas que reciben el tráfico, que suelen ser las que llevan parámetros.
• Optimizar imágenes para bajar el LCP sin mirar antes el TTFB, que es el tramo que lo arrastra.
• Dejar redirecciones internas antiguas porque «funcionan»: funcionan para el usuario y cuestan en cada visita y en cada rastreo.