Definición
El TTFB (Time To First Byte) es el tiempo que transcurre desde que el navegador pide una página hasta que recibe el primer byte de la respuesta.
Es la métrica menos glamurosa del rendimiento web y una de las más determinantes, por una razón matemática: es el suelo de todo lo demás. Si tu servidor tarda 1,5 segundos en empezar a responder, ninguna optimización de imágenes, de CSS o de JavaScript va a conseguir que la página se vea antes de ese segundo y medio.
No es una métrica de Core Web Vitals, y alimenta directamente al LCP, que sí lo es. Un TTFB malo hace imposible un LCP bueno.
Qué se mide exactamente
El TTFB no es solo el tiempo de tu servidor. Suma varias cosas:
- Redirecciones, si las hay. Cada salto es una petición completa.
- Resolución DNS: traducir el dominio a una IP.
- Conexión TCP y negociación TLS: establecer la conexión segura.
- Tiempo de proceso en el servidor: consultar la base de datos, generar el HTML.
- Viaje de red hasta el navegador.
Saber esto importa porque el punto 4 suele ser el culpable, pero no siempre. Una cadena de tres redirecciones puede añadir medio segundo antes de que tu servidor haya empezado a trabajar.
Qué valor es bueno
La referencia habitual:
- Bueno: menos de 800 ms.
- Mejorable: entre 800 y 1.800 ms.
- Malo: más de 1.800 ms.
Y una comparación útil: una web estática bien alojada responde en 50-200 ms. Cuando ves 1.500 ms, casi siempre hay una aplicación consultando una base de datos sin caché por medio.
Cómo bajarlo
Por orden de impacto real:
Cachear la respuesta. Si la página es la misma para todo el mundo, generarla una vez y servirla desde caché convierte 1.200 ms en 30 ms. Es la palanca con más diferencia.
Servir HTML estático. El caso extremo del anterior: el trabajo se hizo al compilar y el servidor solo entrega ficheros.
Arreglar las consultas lentas. Muchas veces el TTFB alto es una consulta a la que le falta un índice. Es la optimización más barata que existe.
Eliminar las cadenas de redirecciones. Que la URL antigua apunte al destino final en un salto.
CDN si tu público está lejos del servidor.
Mejor alojamiento. Un compartido saturado tiene un techo que no se puede optimizar desde el código.
Ejemplo práctico
En esta web el TTFB es bajo por diseño, y la razón es la arquitectura, no un ajuste.
Las 134 páginas del diccionario son ficheros HTML generados al compilar. Cuando llega una petición, el servidor no consulta ninguna base de datos ni ejecuta nada: localiza el fichero y lo manda. Eso es lo que permite tiempos de respuesta de décimas de segundo en un alojamiento compartido de los baratos.
Donde sí es un problema real es en el CRM de IMDICA. Ahí cada pantalla consulta la base de datos, y hubo un caso claro: un informe de ventas por cliente tardaba catorce segundos. El TTFB era ese: el servidor no empezaba a responder hasta terminar la consulta.
La causa no era el servidor ni el alojamiento: era una columna sin índice en una tabla de cientos de miles de filas. Con el índice, cuarenta milisegundos. Trescientas cincuenta veces más rápido con una línea de SQL.
Esa es la lección que me llevo: cuando el TTFB es malo, la respuesta casi nunca es contratar un servidor más grande. Es averiguar qué está haciendo el servidor durante ese tiempo.
Por qué importa más allá del usuario
Alimenta el LCP. Y el LCP sí es un factor de posicionamiento.
Afecta al rastreo. Googlebot ajusta su ritmo según lo que tarda tu servidor. Un sitio lento se rastrea menos, y en webs grandes eso significa que hay páginas a las que no llega.
Se nota en móvil. Con una conexión peor, cada milisegundo de servidor se suma a una red ya lenta.
Errores comunes
- Optimizar imágenes con un TTFB de dos segundos. Estás puliendo lo de arriba mientras el suelo está hundido. Primero el servidor.
- Medir solo desde tu ordenador. Estás cerca del servidor y probablemente tienes la respuesta cacheada. Mide desde varias ubicaciones y con datos de usuarios reales.
- Confundir TTFB con velocidad de carga. Es solo el principio.
- Culpar al alojamiento sin comprobar. Muchas veces es una consulta lenta o un plugin.
- Ignorar las redirecciones. Se suman antes de que tu servidor haga nada.
Cuándo mirarlo
Es lo primero que miraría en cualquier auditoría de rendimiento, porque condiciona todo lo demás. Si está por encima de un segundo, todo el trabajo de optimización del frontend va a rendir poco.
Se ve en el informe de red de las herramientas del navegador, en PageSpeed Insights y en el informe de estadísticas de rastreo de Search Console, que da el tiempo medio de respuesta que Google experimenta — que es el dato que de verdad importa.
