≡En resumen
- El TTFB mide cuánto tarda en llegar el primer byte de la respuesta desde que empieza la navegación, no solo lo que tarda el servidor en pensar.
- web.dev considera bueno un TTFB de 0,8 segundos o menos en el percentil 75 de las visitas.
- No es una Core Web Vital, pero un TTFB alto hace casi imposible tener un buen LCP.
- Las causas más habituales son un servidor lento o saturado, páginas generadas sin caché, redirecciones y la distancia entre usuario y servidor.
- Las soluciones de mayor impacto son la caché de página completa, una CDN y un hosting dimensionado para tu tráfico.
01 ¿Qué es el TTFB?
Durante años se habló del TTFB como «tiempo de respuesta del servidor», pero la definición actual de web.dev es más amplia: incluye también la resolución DNS, la conexión y las redirecciones. Por eso dos usuarios de la misma web pueden tener TTFB muy distintos según su red y su distancia al servidor. Es una pieza básica de la optimización de velocidad, porque es lo primero que ocurre en cada carga.
02 Qué fases incluye el TTFB
-
1
Redirecciones
Si la URL pedida redirige (de http a https, de sin www a con www…), cada salto añade una petición completa.
-
2
Arranque del service worker
Si la web tiene un service worker, el navegador puede tener que iniciarlo antes de continuar.
-
3
Búsqueda DNS
El navegador traduce el dominio a una dirección IP; un proveedor de DNS lento se nota aquí.
-
4
Conexión y negociación TLS
Se abre la conexión con el servidor y se establece el cifrado HTTPS.
-
5
Petición y espera
El navegador pide la página y espera a que el servidor la genere y empiece a enviarla. En muchas webs, esta es la fase más larga.
Dos de estas fases dependen de servicios que a veces se olvidan: la resolución DNS, que puedes acelerar con un proveedor de DNS rápido, y las redirecciones, que suelen acumularse tras migraciones o cambios de dominio.
03 ¿Qué es un buen TTFB? Umbrales de web.dev
≤ 0,8 s
TTFB bueno
Fuente: web.dev, Time to First Byte (TTFB)
0,8-1,8 s
TTFB que necesita mejorar
Fuente: web.dev, Time to First Byte (TTFB)
> 1,8 s
TTFB malo
Fuente: web.dev, Time to First Byte (TTFB)
Como en las Core Web Vitals, el valor que cuenta es el percentil 75: el 75 % de las visitas reales debe estar por debajo del umbral. web.dev aclara que el TTFB no es una Core Web Vital y que no es imprescindible cumplir el umbral «bueno» si tu LCP y tu primera pintura son buenos, por ejemplo en aplicaciones que se renderizan en el navegador. Pero un TTFB de 2 segundos deja muy poco margen para que el LCP baje de los 2,5 segundos recomendados.
04 Cómo medir el TTFB
PageSpeed Insights
Muestra el TTFB de usuarios reales de Chrome (datos de CrUX) si tu web tiene tráfico suficiente, además de la prueba de laboratorio.
Chrome DevTools
En la pestaña Network, selecciona el documento y abre Timing: la fase «Waiting for server response» es la espera del servidor.
WebPageTest
Permite medir desde distintos países y conexiones, útil para ver el efecto de la distancia y de una CDN.
Terminal
Con curl puedes obtener el tiempo hasta el primer byte de una URL sin navegador, ideal para comparar antes y después.
Librería web-vitals
Recoge el TTFB de tus visitantes reales y lo envía a tu analítica para ver su evolución.
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://www.tudominio.com/
Lánzalo varias veces: la primera petición suele ser más lenta si la caché estaba vacía. Si la segunda baja mucho, tu caché funciona; si no, el servidor genera la página en cada visita.
En PageSpeed Insights, el diagnóstico de latencia de la solicitud del documento (Document request latency), que desde octubre de 2025 agrupa los antiguos avisos de tiempo de respuesta del servidor, redirecciones y compresión, es la señal de laboratorio más directa de un TTFB alto. Para saber qué parte del servidor tarda, añade la cabecera Server-Timing con los tiempos de base de datos o de renderizado: aparecerán en DevTools junto a cada petición.
05 Causas de un TTFB alto
| Causa | Síntoma |
|---|---|
| Hosting insuficiente o compartido saturado | TTFB alto y variable, que empeora en horas punta |
| Páginas generadas en cada visita, sin caché | Todas las páginas tardan lo mismo, aunque se repita la petición |
| Consultas lentas, plugins pesados o versión antigua de PHP | TTFB alto sobre todo en búsquedas, carritos o páginas con filtros |
| Servidor lejos del usuario y sin CDN | Bueno desde España, malo desde Latinoamérica o viceversa |
| Cadenas de redirecciones | DevTools muestra varias peticiones 301 o 302 antes del documento |
| DNS o negociación TLS lentos | Fases iniciales largas en la cascada de WebPageTest |
06 Cómo reducir el TTFB
-
1
Activa la caché de página completa
Guarda el HTML ya generado y sírvelo sin ejecutar PHP ni consultar la base de datos. Es la mejora de mayor impacto en webs con CMS.
-
2
Usa una CDN
Sirve las páginas desde servidores cercanos al usuario, con protocolos modernos como HTTP/3. Incluso una caché corta en el borde reduce mucho las peticiones al origen.
-
3
Dimensiona el hosting
CPU, memoria y versión de PHP o Node adecuadas a tu tráfico. Un servidor que llega al límite dispara el TTFB en los picos.
-
4
Optimiza la aplicación
Revisa consultas lentas, añade caché de objetos (Redis, Memcached) y elimina plugins o procesos que se ejecutan en cada petición.
-
5
Elimina redirecciones
Enlaza directamente a la URL final y usa la cabecera Strict-Transport-Security para evitar el salto de http a https.
-
6
Adelanta recursos con 103 Early Hints
El servidor puede indicar al navegador qué CSS o fuentes descargar mientras termina de generar la página.
Entender la caché es la base de casi todas estas mejoras. En infraestructura, pasar a cloud hosting permite ampliar recursos cuando crece el tráfico sin cambiar de proveedor. Si tu web es un WordPress, tienes los plugins que funcionan y los que no en nuestra guía sobre WordPress lento.
07 TTFB, Core Web Vitals y SEO
Google no usa el TTFB como Core Web Vital, pero sí usa el LCP, y el LCP empieza a contar desde el mismo instante que el TTFB. Un servidor lento también frena el rastreo: si cada página tarda en responder, Googlebot rastrea menos URL con los mismos recursos, algo que se nota en webs grandes.
Por eso el TTFB es uno de los primeros puntos que revisamos en una auditoría SEO técnica, y el punto de partida de cualquier proyecto de optimización de la velocidad web: de nada sirve comprimir imágenes si la página tarda dos segundos en empezar a llegar.
Preguntas frecuentes sobre Time to First Byte (TTFB)
Es el tiempo hasta el primer byte: lo que tarda el navegador en recibir el primer byte de la respuesta desde que empieza a navegar a una página. Incluye redirecciones, DNS, conexión y la espera al servidor.
Según web.dev, 0,8 segundos o menos en el percentil 75 de las visitas. Entre 0,8 y 1,8 segundos necesita mejorar y por encima de 1,8 segundos es malo.
No. Las Core Web Vitals son LCP, INP y CLS. Pero el TTFB influye directamente en el LCP, porque la carga no puede avanzar hasta que llega el primer byte.
En PageSpeed Insights (datos reales de Chrome), en la pestaña Network de Chrome DevTools, en WebPageTest o con curl desde la terminal.
Lo más habitual es que el servidor genere cada página sin caché, que el hosting esté saturado, que haya consultas o plugins lentos o que el usuario esté lejos del servidor sin CDN.
Sí, sobre todo para usuarios lejanos, porque sirve la página desde un servidor cercano. El efecto es máximo cuando la CDN también cachea el HTML.
El TTFB mide solo hasta que llega el primer byte del HTML. El tiempo de carga incluye además la descarga de imágenes, estilos y scripts y el pintado de la página.
Fuentes consultadas
Sobre el autor
Germán Gutiérrez
Development Manager en appyweb
Dirige el equipo de desarrollo de appyweb: aplicaciones web y móviles, SaaS, integraciones y arquitectura de software.
Ver perfil en LinkedIn ↗