Respuesta corta: el tiempo hasta el primer byte (TTFB) es el tiempo entre la solicitud de una página y el momento en que empieza a llegar el primer byte de la respuesta. Todas las demás métricas de carga van después, así que un servidor lento frena la página entera.
Qué suma el TTFB
El TTFB es la suma de cinco fases de la solicitud, así que un retraso en cualquiera de ellas se nota en él.
| Fase | Qué pasa | Qué la acorta |
|---|---|---|
| Redirecciones | El navegador va a otra dirección antes de llegar a la página | Enlaces a la dirección final, con https y la barra correcta |
| Inicio del service worker | Si el sitio tiene un service worker, arranca antes de la solicitud | Servir desde su caché los documentos que cambian poco |
| Búsqueda de DNS | El navegador busca la dirección del servidor | Una CDN, que suele resolver el DNS muy rápido |
| Conexión y TLS | El navegador abre una conexión segura con el servidor | Una CDN con TLS moderno, como TLS 1.3 |
| Solicitud | El servidor prepara la respuesta hasta que llega el primer byte | Un buen hosting, una caché de páginas y menos complementos pesados |
De web.dev, «Tiempo hasta el primer byte (TTFB)» y «Optimiza el tiempo hasta el primer byte», consultadas el 3 de noviembre de 2026.
Qué es un buen TTFB
web.dev considera bueno un TTFB de 0.8 segundos o menos y deficiente uno de más de 1.8 segundos. La meta es un servidor lo bastante rápido para que el percentil 75 de los visitantes tenga un buen First Contentful Paint (FCP).
Como el TTFB no forma parte de las Core Web Vitals, no llegar a esa marca no es un problema mientras no frene las métricas que importan.
Nuestra guía de Core Web Vitals explica el LCP, el INP y el CLS.
Cómo medir el TTFB
web.dev recomienda los datos de campo como fuente principal, porque incluyen las redirecciones, mientras que las herramientas de laboratorio suelen probar la dirección final y no ven ese retraso. PageSpeed Insights muestra datos de campo y de laboratorio de los sitios públicos del Chrome User Experience Report.
La auditoría del tiempo de respuesta del servidor de Lighthouse no cuenta la búsqueda de DNS ni las redirecciones, así que solo cubre una parte del TTFB. Para ver si una caché esconde un servidor lento, prueba páginas menos visitadas o añade un parámetro de URL que dé una copia sin caché.
Nuestra guía de PageSpeed Insights muestra dónde está cada cifra.
Cómo bajar el TTFB
- Empieza por los datos de campo de PageSpeed Insights y usa después las herramientas de laboratorio para encontrar la causa.
- Comprueba que tu hosting le da a tu sitio memoria suficiente y mantiene al día el software del servidor.
- Guarda las páginas en caché para que el servidor no prepare cada una en cada visita, y deja un parámetro de URL que se salte la caché para las pruebas.
- Asegúrate de que las etiquetas de campaña, como utm, no dividan la caché en copias de la misma página.
- Enlaza a la dirección final, con https y la barra correcta, y da esa dirección a los anunciantes y a los boletines.
- Pon una CDN delante del sitio para tener un DNS rápido, TLS moderno y copias cerca de tus visitantes.
- En WordPress, revisa la cantidad y la calidad de tus complementos y tu tema.
Nuestra guía de la redirección 301 explica cuándo vale la pena mantener una redirección.
Nuestro propio TTFB
Leímos 12 de nuestras páginas 5 veces cada una el 3 de noviembre, desde otro de nuestros servidores. Un visitante lejos o con datos móviles verá más tiempo. Desde nuestra caché de páginas, la mediana del TTFB fue de 41 milisegundos y la lectura más lenta, de 58.
Con un parámetro de URL que se salta la caché, las mismas páginas tardaron una mediana de 986 milisegundos, hasta 1,279. Es el tiempo que necesita WordPress para preparar una página, entre bueno y deficiente sin la caché. La conexión y el TLS se llevaron 31 milisegundos de cada lectura.
Los enlaces con etiquetas de campaña reciben igual la copia de la caché: nuestra caché ignora los parámetros utm y los identificadores de clic como gclid y fbclid, y 15 lecturas con etiquetas salieron de ella con una mediana de 45 milisegundos.
Una redirección desde http o www tarda unos 4 milisegundos en nuestro servidor web. Un enlace sin la barra final tarda unos 377, porque esa redirección la prepara WordPress, así que enlazamos siempre con la barra.
Antes de dar por arreglado tu TTFB
- El TTFB de campo en PageSpeed Insights es de 0.8 segundos o menos.
- Una prueba que se salta la caché muestra cuánto necesita tu servidor.
- Las páginas menos visitadas también son rápidas, no solo la de inicio.
- Las etiquetas de campaña no se saltan tu caché de páginas.
- Tus enlaces y tus anuncios apuntan a la dirección final.
- Cada redirección que queda es un solo salto, no una cadena.
RecuerdaEl TTFB es la espera antes de que llegue nada: redirecciones, DNS, la conexión y el trabajo de tu servidor. Una caché puede esconder un servidor lento, así que prueba también sin ella y arregla primero las redirecciones que controlas.
Si quieres que revisemos la velocidad y las redirecciones de tu sitio, mira nuestro servicio de SEO técnico.
Respuestas rápidas sobre el TTFB
¿El TTFB importa más en las aplicaciones de una sola página?
Sí. En las aplicaciones de una sola página, el HTML inicial necesita JavaScript para llenar el contenido. Por eso web.dev dice que ahí el TTFB más bajo posible es aún más importante, para que el navegador empiece antes. Un sitio que se prepara en el servidor puede tener un TTFB más alto y aun así un mejor FCP y LCP.
¿Una CDN baja el TTFB?
Normalmente sí. Una CDN sirve copias desde servidores más cerca de tus visitantes, suele resolver el DNS muy rápido y usa protocolos modernos como HTTP/2 o HTTP/3 y TLS 1.3. El contenido personalizado no sirve para la caché de la CDN, así que esas solicitudes siguen llegando a tu servidor.
¿Las 103 Early Hints mejoran el TTFB?
Cuentan como los primeros bytes, así que el TTFB puede parecer rápido mientras el servidor aún prepara la página. web.dev dice que ayudan sobre todo en sitios con mucho tiempo de backend y poco en sitios estáticos, y sugiere medir el tiempo real del servidor con Server-Timing. También hacen más difícil comparar el TTFB entre plataformas.
¿WordPress hace más lento el TTFB?
Puede. web.dev dice que el rendimiento de WordPress depende de la cantidad y la calidad de los complementos y del tema. En nuestro propio sitio de WordPress, preparar una página tardó una mediana de 986 milisegundos, por eso servimos las páginas desde una caché.
¿Las redirecciones cuentan en el TTFB?
Sí, el tiempo de redirección es la primera fase del TTFB. Además de quitar las redirecciones de tu propio sitio, web.dev sugiere el encabezado HSTS. Con él, los navegadores van directo a https en las visitas siguientes en vez de pasar por http.
Fuentes
Consultadas el 3 de noviembre de 2026. web.dev: Tiempo hasta el primer byte (TTFB) y Optimiza el tiempo hasta el primer byte. Nuestro caso: 12 de nuestras páginas, el 3 de noviembre de 2026.