Tiempo hasta el primer byte (TTFB)

TL;DR — El Time to First Byte es el tiempo que el navegador espera, después de pedir una página, antes de que llegue el primer byte de la respuesta. Es una medida de la capacidad de respuesta del servidor. Un buen TTFB es de 0,8 segundos o menos. No es una métrica Core Web Vital, pero uno lento arrastra hacia abajo las métricas que sí lo son, porque nada en la página puede comenzar hasta que aparezca ese primer byte.

Qué es el TTFB

Cuando haces clic en un enlace, tu navegador envía una solicitud a un servidor y luego espera. El Time to First Byte (TTFB) es la duración de esa espera: desde el momento en que comienza la solicitud hasta el momento en que llega el primer byte de la respuesta.

No es solo “qué tan rápido piensa el servidor”. Suceden muchas cosas antes de que tu navegador siquiera hable con la máquina correcta: puede seguir una redirección, buscar el dominio en el DNS, abrir una conexión y negociar el protocolo de enlace seguro (TLS). El TTFB incluye todo eso, y luego suma el tiempo de procesamiento del propio servidor, y detiene el cronómetro en el primer byte de vuelta.

Qué se considera bueno

La guía de web.dev de Google es simple: apunta a un TTFB de 0,8 segundos o menos. Por encima de 1,8 segundos se considera deficiente. La mayoría de los sitios deberían poder alcanzar la marca de bueno, y muchos no lo hacen, que es exactamente por lo que vale la pena comprobarlo.

Por qué importa aunque no sea una métrica “core”

Escucharás mucho sobre las Core Web Vitals: LCP, INP y CLS. El TTFB no es una de ellas. Pero se encuentra debajo de las relacionadas con la carga: tanto First Contentful Paint como Largest Contentful Paint incluyen el TTFB en su medición. El navegador no puede pintar nada hasta que los bytes comiencen a llegar. Así que un TTFB lento pone un techo a la velocidad que tu página puede sentir.

La conclusión práctica: el TTFB no te posiciona por sí solo, pero uno malo frena silenciosamente las métricas que sí lo hacen.

Las soluciones habituales, en términos sencillos

• Usa una CDN. Coloca una copia de tu sitio en servidores físicamente más cercanos a tus visitantes, por lo que el viaje de ida y vuelta es más corto.
• Almacena en caché tus páginas. Si el servidor puede devolver una copia ya preparada en lugar de reconstruir la página cada vez, el primer byte llega mucho antes.
• Consigue un mejor alojamiento. Un servidor y una base de datos más rápidos es la solución más directa.
• Reduce las redirecciones. Cada redirección es un viaje de ida y vuelta adicional antes de que la página real siquiera comience a cargarse.

¿Quieres la versión completa (los umbrales exactos, la relación con el LCP, la confusión de umbrales entre Lighthouse y CrUX, Early Hints y cómo medirlo)? Cambia a la pestaña Avanzado.

TL;DR — El TTFB es el tiempo desde el inicio de la solicitud hasta que llega el primer byte de la respuesta: la suma del tiempo de redirección, el inicio del service worker, la búsqueda de DNS, la conexión + negociación de TLS y la propia solicitud, hasta ese primer byte. No es una Core Web Vital; es una métrica fundamental y de diagnóstico que alimenta el FCP y el LCP. web.dev: bueno es ≤0,8 s, deficiente es >1,8 s (percentil 75). Es tanto una métrica de campo como de laboratorio. La auditoría “Reduce server response times” de Lighthouse es más limitada: marca el tiempo del servidor por encima de ~600 ms, no el TTFB completo, y a partir de Lighthouse 13 vive dentro de la información “Document request latency”. Soluciónalo con una CDN, caché de edge/HTML, alojamiento más rápido, menos redirecciones, 103 Early Hints y TLS eficiente. Y un TTFB alto no siempre significa un sitio lento.

Qué mide realmente el TTFB

El TTFB mide el tiempo entre comenzar a navegar a una página y cuando el primer byte de la respuesta comienza a llegar. Lo que la gente entiende mal es tratarlo como puro tiempo de procesamiento del backend. No lo es. Es la suma de todo lo que tiene que terminar antes de que ese primer byte pueda volver:

1. Tiempo de redirección
2. Tiempo de inicio del service worker (si aplica)
3. Búsqueda de DNS
4. Conexión y negociación de TLS
5. La solicitud — hasta el punto en que el primer byte de la respuesta ha llegado

El procesamiento del servidor está ahí, pero también todo el coste de configuración de la conexión. Esa distinción importa en cuanto empiezas a leer las herramientas, porque no todas miden la misma parte (más sobre esto a continuación).

No es una Core Web Vital

Lo diré claramente porque es el error más común: TTFB no es una Core Web Vital. Las tres Core Web Vitals son LCP (carga), INP (interactividad) y CLS (estabilidad visual). TTFB es una métrica fundamental y de diagnóstico: el propio marco de Google es que es “una métrica fundamental para medir el tiempo de configuración de la conexión y la capacidad de respuesta del servidor web tanto en el laboratorio como en el campo.”

Google también es explícito en que no es estrictamente necesario alcanzar el umbral de TTFB bueno: como no es una Core Web Vital, “no es absolutamente necesario que los sitios cumplan el umbral de TTFB ‘bueno’, siempre que no impida su capacidad para obtener buenos resultados en las métricas que importan.” Esa última cláusula es la trampa: para la mayoría de los sitios, un TTFB malo sí impide obtener buenos resultados en las métricas que importan.

Cómo limita FCP y LCP

TTFB precede a todas las métricas de carga centradas en el usuario. Tanto First Contentful Paint como Largest Contentful Paint incluyen TTFB en su medición: el reloj de esas métricas ya está corriendo mientras esperas el primer byte. web.dev desglosa LCP en subpartes y TTFB es la primera de ellas, por eso no puedes tener un LCP rápido sobre un TTFB lento.

Aquí es también donde los datos del mundo real se vuelven contundentes. El Web Almanac del HTTP Archive encontró que en sitios con LCP malo, solo TTFB consumía aproximadamente 2,27 segundos — casi todo el presupuesto de 2,5 segundos de “LCP bueno” — antes de que cualquier imagen o texto comenzara a renderizarse. Si tu LCP es malo y tu contenido en la página parece optimizado, TTFB es el primer lugar donde yo miraría.

Así que la historia del ranking es indirecta pero real: TTFB no es una señal de ranking de Google (las señales de ranking son LCP, INP y CLS; TTFB no está nombrado en ese conjunto). Pero está integrado en LCP, que sí es una señal de ranking. El camino pasa por LCP, no directamente por TTFB.

Umbrales: bueno, necesita mejoras, malo

La guía de web.dev, medida en el percentil 75 de las cargas de usuarios reales:

• Bueno: ≤ 0,8 s
• Malo: > 1,8 s

“La mayoría de los sitios deberían esforzarse por tener un TTFB de 0,8 segundos o menos.” Vale la pena conocer la historia: Google movió la línea de “bueno” de 500 ms a 800 ms en 2022, y los datos más antiguos se recalcularon bajo el nuevo estándar — así que no compares números históricos de TTFB sin comprobar qué umbral usaron.

La confusión entre 600 ms y 800 ms

Esto confunde a mucha gente, así que vale la pena ser precisos. Hay dos números diferentes circulando:

• Umbral de TTFB de CrUX / web.dev: 800 ms. Este es el umbral de campo para el TTFB completo (DNS + conexión + TLS + redirecciones + tiempo del servidor).
• Auditoría de Lighthouse “Reduce server response times”: ~600 ms. Esta es una auditoría de laboratorio que marca cuando el navegador espera más de unos 600 ms a que el servidor responda a la solicitud del documento principal. Crucialmente, mide solo el tiempo de respuesta del servidor — no incluye DNS, configuración de la conexión ni TLS.

Así que el número de Lighthouse parece más estricto, pero está midiendo una parte más estrecha. Como dicen los documentos, “el tiempo de respuesta del servidor es solo una parte del TTFB completo.” No trates una auditoría de Lighthouse aprobada como prueba de un buen TTFB de campo, y no entres en pánico porque 600 < 800 signifique que los umbrales se contradicen — miden cosas diferentes.

Una nota de versión: a partir de Lighthouse 13, esta auditoría ya no está sola — se ha integrado en la información más amplia de “Document request latency”. La comprobación subyacente de respuesta del servidor de ~600 ms es la misma; solo se muestra de manera diferente según la versión de Lighthouse que generó tu informe.

Campo y laboratorio — ambos

TTFB es una de las métricas que puedes leer en ambos mundos. En el campo, proviene de CrUX (usuarios reales de Chrome), que aparece en PageSpeed Insights y Search Console. En el laboratorio, Chrome DevTools lo etiqueta como “Waiting (TTFB)” en el panel de red (“el navegador está esperando el primer byte de una respuesta”), y herramientas como WebPageTest y Lighthouse también lo informan. Una advertencia de campo: en CrUX, TTFB todavía se considera algo experimental: excluye algunos tipos de navegación avanzados, como las navegaciones prerenderizadas y de caché de retroceso/avance, por lo que los promedios de campo pueden leerse un poco pesimistas en relación con lo que los usuarios realmente sienten.

Un TTFB alto no siempre significa un sitio lento

Aquí está el matiz que los números de umbral ocultan. Una página renderizada en el servidor puede publicar un TTFB más alto que una renderizada en el cliente y aun así ofrecer un FCP y LCP mejores — porque cuando ese primer byte finalmente llega, es HTML completo que el navegador puede pintar de inmediato, en lugar de un caparazón delgado que luego tiene que buscar y ejecutar un paquete de JavaScript antes de que aparezca algo. Google lo dice directamente: “a server-rendered site that does not require as much client-side work could have a higher TTFB, but better FCP and LCP values than an entirely client-rendered experience.” (traducción) «un sitio renderizado en el servidor que no requiere tanto trabajo del lado del cliente podría tener un TTFB más alto, pero mejores valores de FCP y LCP que una experiencia completamente renderizada en el cliente».

El lado opuesto: para una aplicación de una sola página renderizada en el cliente, TTFB determina cuándo el paquete de JavaScript incluso comienza a cargarse, por lo que un TTFB bajo importa más allí, no menos. No optimices TTFB en el vacío: optimiza toda la cadena de carga y juzga TTFB por lo que hace a FCP y LCP.

Cómo mejorar TTFB

Aproximadamente en orden de prioridad:

• Comienza con el alojamiento. Un backend lento o una consulta de base de datos es un impuesto en cada solicitud, y ninguna cantidad de trabajo de front-end lo elimina. Esto es lo primero a considerar.
• Usa una CDN. Una CDN resuelve el problema de la proximidad: una red distribuida de servidores perimetrales almacena en caché los recursos físicamente más cerca de tus usuarios, reduciendo el costo de velocidad de la luz de la conexión y el protocolo de enlace TLS. Es la solución de mayor retorno de inversión para la mayoría de los sitios, porque la distancia geográfica desde tu origen es un impuesto estructural que nada en el backend puede eliminar. La advertencia: para contenido totalmente dinámico y personalizado que no se puede almacenar en caché, una CDN agrega un salto sin beneficio de acierto de caché — allí la respuesta es la optimización del backend, la computación en el borde o la transmisión.
• Almacena en caché tu HTML, incluso brevemente. Incluso un tiempo de caché corto ayuda notablemente a un sitio ocupado: solo el primer visitante en esa ventana paga la latencia completa de vuelta al origen; todos los demás obtienen la copia en caché.
• Elimina las redirecciones. Las redirecciones son un contribuyente común al TTFB alto: cada una es un viaje de ida y vuelta antes de que comience la respuesta real. Corta las que están bajo tu control.
• Transmite el marcado al navegador. Los navegadores procesan el marcado de manera eficiente cuando se transmite en fragmentos a medida que llega. Muchos marcos de SSR admiten la transmisión, pero está desactivada; activarla puede reducir el TTFB en páginas dinámicas sin ningún cambio de infraestructura.
• Usa 103 Early Hints. El código de estado 103 es una respuesta preliminar que el servidor puede enviar mientras el backend todavía está preparando el marcado, indicando al navegador que comience a descargar recursos críticos para el renderizado temprano. No reduce el TTFB en sí mismo — de hecho, un 103 puede contar como el “primer byte” — pero reduce el impacto de un TTFB alto. Shopify y Cloudflare han informado varios cientos de milisegundos de mejora en LCP, en algunos casos cerca de un segundo.
• Negocia TLS de manera eficiente y optimiza el inicio del service worker. Un service worker que aún no ha comenzado agrega su tiempo de inicio al TTFB; una vez en ejecución, su caché (stale-while-revalidate, o un modelo de shell de aplicación para SPA) puede reducir drásticamente el TTFB.

Dónde están realmente los sitios

La razón por la que esto merece tu atención: es un problema persistente en toda la web. La tasa móvil de TTFB bueno del Web Almanac apenas se ha movido en cinco años — rondando el 41–42 % — lo que significa que la mayoría de los sitios móviles todavía no tienen un TTFB “bueno”. Ese estancamiento es, francamente, una oportunidad. Para un sitio con mucho servidor que falla en LCP, el TTFB suele ser la corrección de mayor apalancamiento disponible.

Esta página forma parte del clúster de rendimiento web, que se encuentra bajo Core Web Vitals. Para las métricas en las que influye el TTFB, consulta Largest Contentful Paint y First Contentful Paint; para medirlo en usuarios reales y en el laboratorio, consulta CrUX, PageSpeed Insights y Lighthouse.

Resumen de IA

Una versión condensada de la versión avanzada:

• TTFB = la espera del primer byte. Tiempo desde el inicio de la solicitud hasta que llega el primer byte de la respuesta — la suma del tiempo de redirección, el inicio del service worker, la búsqueda de DNS, la negociación de conexión + TLS y la propia solicitud. No solo el procesamiento del servidor.
• NO es una Core Web Vital. Las Core Web Vitals son LCP, INP y CLS. El TTFB es una métrica fundamental y diagnóstica.
• Limita FCP y LCP. Ambos incluyen el TTFB, por lo que un TTFB lento establece un techo sobre la rapidez con la que puede cargar una página. En sitios con LCP deficiente, el TTFB por sí solo era de ~2,27 s — casi todo el presupuesto de LCP bueno de 2,5 s.
• Clasificaciones: indirectas. El TTFB no es una señal de clasificación de Google, pero está integrado en LCP, que sí lo es. El camino pasa por LCP.
• Umbrales (percentil 75): bueno ≤ 0,8 s, deficiente > 1,8 s. La línea de “bueno” pasó de 500 ms a 800 ms en 2022.
• 600 ms frente a 800 ms: la auditoría “Reduce server response times” de Lighthouse marca ~600 ms de tiempo de servidor únicamente — más estrecho que el umbral de campo de TTFB completo de 800 ms. “Server response time is only part of the full TTFB.” (traducción) «El tiempo de respuesta del servidor es solo una parte del TTFB completo.» A partir de Lighthouse 13, esta auditoría se encuentra dentro de la información “Document request latency”.
• Campo y laboratorio: CrUX/PSI/Search Console (campo); DevTools “Waiting (TTFB)”, WebPageTest, Lighthouse (laboratorio).
• TTFB alto ≠ sitio lento: una página SSR puede tener un TTFB más alto pero mejor FCP/LCP que una renderizada en el cliente, porque el primer byte es HTML completo.
• Correcciones (prioridad): hosting primero, luego CDN, caché de HTML, menos redirecciones, streaming, 103 Early Hints, TLS eficiente, inicio del service worker.
• Estado de la web: el TTFB bueno móvil se ha mantenido plano en ~41–42 % durante cinco años — una oportunidad real.

Documentación oficial

Documentación de fuente primaria de los equipos de Chrome y web.dev de Google.

• Time to First Byte (TTFB) — la definición, los cinco componentes, los umbrales de 0,8 s / 1,8 s, por qué no es una Core Web Vital y su relación con FCP y LCP.
• Optimize TTFB — la guía de optimización: hosting primero, luego CDN, caché, redirecciones, streaming, 103 Early Hints y service workers.
• Reduce server response times — la auditoría de Lighthouse (umbral de ~600 ms de tiempo de servidor) y cómo difiere del TTFB completo. A partir de Lighthouse 13, se integra en la información “Document request latency”.
• Web Vitals — dónde se sitúa el TTFB en la taxonomía de métricas: una métrica complementaria/diagnóstica, con LCP, INP y CLS como Core Web Vitals.
• Largest Contentful Paint (LCP) — confirma que LCP incluye los retrasos del TTFB.
• First Contentful Paint (FCP) — confirma que FCP incluye el TTFB y enumera “reduce server response times (TTFB)” como una corrección.
• Core Web Vitals (Google Search Central) — los documentos de la señal de clasificación mencionan solo LCP, INP y CLS; el TTFB no está listado.
• 103 Early Hints — el código de respuesta temprana, la compatibilidad del navegador/servidor y los resultados del mundo real.

Citas de la fuente

Declaraciones oficiales de los equipos de web.dev y Chrome de Google. Cada enlace es un enlace profundo que salta al pasaje citado en la página de origen donde se verificó uno.

web.dev — qué es TTFB

• “TTFB is a metric that measures the time between starting navigating to a page and when the first byte of a response begins to arrive.” (traducción) «TTFB es una métrica que mide el tiempo entre comenzar a navegar a una página y cuando el primer byte de una respuesta comienza a llegar». Ir a la cita
• “Time to First Byte (TTFB) is a foundational metric for measuring connection setup time and web server responsiveness in both the lab and the field.” (traducción) «El tiempo hasta el primer byte (TTFB) es una métrica fundamental para medir el tiempo de configuración de la conexión y la capacidad de respuesta del servidor web tanto en el laboratorio como en el campo». Ir a la cita

web.dev — umbrales

• “Good TTFB values are 0.8 seconds or less, and poor values are greater than 1.8 seconds.” (traducción) «Los valores buenos de TTFB son 0,8 segundos o menos, y los valores deficientes son mayores que 1,8 segundos». Ir a la cita

web.dev — no es una métrica Core Web Vitals

• “Because TTFB isn’t a Core Web Vitals metric, it’s not absolutely necessary that sites meet the ‘good’ TTFB threshold, provided that it doesn’t impede their ability to score well on the metrics that matter.” (traducción) «Debido a que TTFB no es una métrica de Core Web Vitals, no es absolutamente necesario que los sitios cumplan el umbral “bueno” de TTFB, siempre que no impida su capacidad de obtener buenos resultados en las métricas que importan». Ir a la cita

web.dev — relación con FCP y LCP

• “Because TTFB precedes user-centric metrics such as First Contentful Paint (FCP) and Largest Contentful Paint (LCP)…” (traducción) «Debido a que TTFB precede a métricas centradas en el usuario, como First Contentful Paint (FCP) y Largest Contentful Paint (LCP)…» Ir a la cita
• En un sitio renderizado en el servidor: “a server-rendered site that does not require as much client-side work could have a higher TTFB, but better FCP and LCP values than an entirely client-rendered experience.” (traducción) «un sitio renderizado en el servidor que no requiere tanto trabajo del lado del cliente podría tener un TTFB más alto, pero mejores valores de FCP y LCP que una experiencia completamente renderizada en el cliente». (web.dev, “Time to First Byte”)

Lighthouse — tiempo de respuesta del servidor vs TTFB completo

• “Server response time is only part of the full Time to First Byte (TTFB).” (traducción) «El tiempo de respuesta del servidor es solo parte del tiempo completo hasta el primer byte (TTFB)». (Lighthouse, “Reduce server response times.”)

Patrick Stox — sobre el estado de TTFB (de mi guía de Core Web Vitals de Ahrefs)

• “There are additional Web Vitals that serve as proxy measures or supplemental metrics but are not used in the ranking calculations. The Web Vitals metrics for visual load include Time to First Byte (TTFB) and First Contentful Paint (FCP).” (traducción) «Hay Web Vitals adicionales que sirven como medidas proxy o métricas complementarias, pero no se usan en los cálculos de clasificación. Las métricas de Web Vitals para la carga visual incluyen Time to First Byte (TTFB) y First Contentful Paint (FCP)». Leer la guía

Lista de verificación de triaje de TTFB

Cuando PageSpeed Insights, Search Console o Lighthouse marquen una respuesta lenta del servidor, trabaja con esta lista:

• Confirma lo que estás viendo: TTFB de campo completo (≤0,8 s es bueno) o la auditoría de Lighthouse “Reduce server response times” (~600 ms, solo tiempo de servidor). No son el mismo número.
• Revisa el campo, no solo el laboratorio: obtén el TTFB de CrUX a través de PageSpeed Insights o del informe de Core Web Vitals de Search Console, en el percentil 75.
• Observa si el TTFB es lo que limita tu LCP: si el LCP es deficiente y el contenido de la página está optimizado, el TTFB es el primer sospechoso.
• Cuenta tus redirecciones: elimina cualquier cadena de redirecciones bajo tu control en las URLs de entrada clave.
• Confirma que una CDN está sirviendo a tus usuarios (PoPs de borde cerca de tu audiencia) y que el almacenamiento en caché de HTML/borde realmente está funcionando, no solo los activos estáticos.
• Perfila el backend: consultas lentas a la base de datos o trabajo pesado del lado del servidor en la solicitud del documento principal.
• Verifica que TLS sea eficiente (protocolo moderno, reanudación de sesión) y que el DNS sea rápido.
• Si la página es SSR dinámico, comprueba si el streaming está habilitado en tu framework: a menudo está desactivado por defecto.
• Considera 103 Early Hints para recursos críticos de renderizado si tu servidor/CDN lo admite.
• Si usas un service worker, comprueba que su inicio no esté añadiendo tiempo al TTFB en la primera carga, y que su estrategia de caché ayude en las cargas repetidas.

Hoja de referencia de TTFB

De qué es la suma el TTFB

1. Tiempo de redirección
2. Inicio del service worker (si lo hay)
3. Búsqueda de DNS
4. Conexión + negociación TLS
5. La solicitud: hasta el primer byte de la respuesta

Umbrales (percentil 75 de cargas de usuarios reales)

Dos umbrales, dos alcances

Datos rápidos

• El TTFB no es un Core Web Vital. Los Core Web Vitals son LCP, INP, CLS.
• Es una métrica tanto de campo como de laboratorio.
• Tanto FCP como LCP incluyen el TTFB: este establece un límite máximo para ellos.
• El impacto en el ranking es indirecto, a través del LCP: el TTFB en sí no es una señal de ranking.
• DevTools lo etiqueta como “Waiting (TTFB)” en el panel de red.
• La línea de “bueno” pasó de 500 ms → 800 ms en 2022.

Prioridad de corrección: hosting → CDN → almacenamiento en caché de HTML/borde → reducir redirecciones → transmitir el marcado → 103 Early Hints → TLS eficiente → inicio del service worker.

Herramientas para medir el TTFB

• PageSpeed Insights — la lectura de campo más fácil: muestra tu TTFB de CrUX (usuarios reales de Chrome) junto con una ejecución de laboratorio, para una URL u origen.
• Search Console — informe de Core Web Vitals — datos de campo agrupados por patrón de URL; el lugar para detectar problemas de TTFB a escala.
• CrUX (Chrome User Experience Report) — el conjunto de datos de campo subyacente; consultable directamente a través de la API de CrUX o BigQuery para tendencias históricas.
• Chrome DevTools — panel de red — pasa el cursor sobre la solicitud del documento principal y lee el tiempo “Waiting (TTFB)” para obtener un desglose preciso de laboratorio entre tiempo de conexión y de servidor.
• Lighthouse — ejecuta la auditoría “Reduce server response times” (aviso de ~600 ms de tiempo de servidor); integrado en DevTools y PageSpeed Insights. A partir de Lighthouse 13, esta comprobación aparece dentro de la información de “Document request latency”.
• WebPageTest — cascadas detalladas con el TTFB desglosado por fase de conexión, y pruebas de múltiples ubicaciones/conexiones para aislar la latencia geográfica.
• Biblioteca JS web-vitals — recopila el TTFB (y el resto) de tus propios usuarios reales en el campo y envíalo a tu analítica.

Errores de TTFB que llevan a la corrección equivocada

Llamar a cada retraso un problema del servidor

El TTFB incluye redirecciones, DNS, configuración de conexión, TLS, inicio del service worker y procesamiento del servidor. Divide la solicitud en fases antes de cambiar el código de la aplicación o el hosting.

Comparar la auditoría de 600 ms de Lighthouse con el umbral de campo de 800 ms

La auditoría de Lighthouse es un diagnóstico de laboratorio más limitado, mientras que la guía de 0,8 segundos describe el TTFB completo. Etiqueta la fuente y el alcance al informar cualquiera de los dos números.

Probar solo desde una ubicación cercana al origen

Un laboratorio cercano puede ocultar la latencia geográfica. Compara regiones o usa datos de usuarios reales antes de asumir que la misma experiencia se aplica a toda la audiencia.

Perseguir el TTFB cuando la página ya es rápida

Un TTFB alto puede ser compatible con una experiencia rápida de transmisión o almacenada en caché. Comprueba si realmente limita el FCP o el LCP antes de priorizarlo sobre un cuello de botella más grande.

Diagnosticar un TTFB lento según el síntoma

La primera solicitud es lenta, pero las solicitudes repetidas son rápidas

Causa probable: cachés frías, configuración de conexión o calentamiento de la aplicación. Solución: inspecciona los encabezados de caché y separa las pruebas en frío de las pruebas en caliente. Confirmación: la cascada muestra qué fase de conexión o servidor desaparece en la solicitud repetida.

El TTFB es lento solo en regiones distantes

Causa probable: distancia física al origen o un fallo de caché de la CDN. Solución: sirve HTML almacenable en caché más cerca de los usuarios y verifica el comportamiento de la caché perimetral. Confirmación: las pruebas regionales muestran una espera más corta sin cambiar el cuerpo de la respuesta.

Una URL tiene un TTFB mucho peor que sus pares de plantilla

Causa probable: redirecciones, una ruta sin caché o trabajo de backend costoso específico de la página. Solución: compara la cadena de redirecciones, el estado de caché y el tiempo del servidor con un par saludable. Confirmación: la solicitud de documento del valor atípico vuelve a acercarse a la línea base de la plantilla.

DevTools y CrUX no coinciden

Causa probable: una sola solicitud de laboratorio no puede representar los dispositivos, ubicaciones, estados de caché y el percentil 75 del campo. Solución: usa la solicitud de laboratorio para diagnosticar y los datos de campo para juzgar la prevalencia. Confirmación: tu distribución de RUM explica qué segmento produce el agregado más lento.

Medir el TTFB desde la línea de comandos

Usa las variables de tiempo de curl para separar el primer byte del DNS, la conexión y la configuración de TLS.

curl -sS -o /dev/null \
  -w 'dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s starttransfer=%{time_starttransfer}s total=%{time_total}s\n' \
  https://example.com/

time_starttransfer es la medición de estilo TTFB del comando. Ejecuta varias solicitudes en frío y en caliente desde más de una región relevante; una sola muestra local no es un punto de referencia de campo.

Leer Navigation Timing en el navegador

const nav = performance.getEntriesByType('navigation')[0];
console.table({
  ttfb: Math.round(nav.responseStart - nav.requestStart),
  dns: Math.round(nav.domainLookupEnd - nav.domainLookupStart),
  connect: Math.round(nav.connectEnd - nav.connectStart),
});

Probar que un cambio de TTFB surtió efecto

Prueba de caché perimetral

Prueba a ejecutar: solicita el mismo documento dos veces con curl -sS -D - -o /dev/null, luego inspecciona los encabezados de estado de caché y edad de la CDN. Resultado esperado: la solicitud repetida se sirve desde la caché según el encabezado documentado de la CDN. Interpretación de fallo: la ruta está omitiendo o expirando inmediatamente la caché. Ventana de monitoreo: inmediata. Disparador de reversión: se sirve HTML personalizado, autenticado o obsoleto a la solicitud incorrecta.

Prueba de eliminación de redirección

Prueba a ejecutar: usa curl -sS -I en la URL pública final e inspecciona la cadena de redirecciones por separado. Resultado esperado: la URL de entrada prevista llega al documento sin un salto evitable. Interpretación de fallo: las reglas de enrutamiento o de host canónico aún agregan un viaje de ida y vuelta. Ventana de monitoreo: inmediata. Disparador de reversión: el cambio rompe la normalización requerida de HTTP a HTTPS o de nombre de host.

Prueba de TTFB de campo

Prueba a ejecutar: compara el TTFB de Navigation Timing o web-vitals posterior al lanzamiento por región y plantilla con la línea base previa al lanzamiento. Resultado esperado: el p75 mejora en los segmentos afectados sin más errores. Interpretación de fallo: la ganancia de laboratorio no llegó a los usuarios reales o trasladó el trabajo a otro lugar. Ventana de monitoreo: a medida que llega el tráfico de RUM; CrUX durante su ventana móvil. Disparador de reversión: la tasa de errores, la corrección de la caché o la latencia visible para el usuario empeoran.

Métricas de TTFB que vale la pena rastrear

TTFB de usuarios reales en p75

Métrica: TTFB del percentil 75 por plantilla, región y clase de dispositivo. Qué te indica: cuánto retrasa la solicitud del documento a la mayoría de las visitas reales antes de que pueda comenzar el renderizado. Cómo obtenerla: Navigation Timing, la librería web-vitals, CrUX o PageSpeed Insights. Referencia / rango realista: 0,8 segundos o menos es el buen objetivo descrito en este artículo; interpreta los segmentos por separado. Cadencia: semanal en RUM y mensual para la tendencia pública móvil.

TTFB con acierto de caché versus TTFB con fallo de caché

Métrica: TTFB p75 dividido por el resultado de caché del CDN. Qué te indica: si el trabajo del origen o la entrega en el borde son los responsables del retraso. Cómo obtenerla: combina las cabeceras de estado de caché de la respuesta con RUM o los registros del CDN. Referencia / rango realista: usa la línea base regional del propio sitio porque el proveedor, la ruta y la personalización difieren. Cadencia: semanal y después de cambios en las reglas de caché.

Participación del TTFB en el LCP

Métrica: TTFB dividido por la duración del LCP para la misma visita. Qué te indica: si el tiempo de servidor y de conexión son la parte limitante de la experiencia de carga. Cómo obtenerla: recopila TTFB y LCP juntos en RUM. Referencia / rango realista: no hay un porcentaje universal honesto; prioriza el TTFB cuando consume constantemente una gran parte del LCP. Cadencia: mensual por plantilla.

Recursos que valen tu tiempo

Mis escritos relacionados

• Core Web Vitals: A Beginner’s Guide — dónde encaja el TTFB entre las métricas de carga y por qué es una métrica complementaria en lugar de una señal de clasificación.
• The Beginner’s Guide to Technical SEO — el panorama general en el que se enmarca el rendimiento del sitio.

Oficial

• TTFB y Optimize TTFB de web.dev — las dos páginas definitivas.
• El artículo del equipo de Chrome sobre 103 Early Hints, con los resultados de Shopify/Cloudflare.

Datos

• El Web Almanac — capítulo de rendimiento de HTTP Archive — los datos de campo de TTFB y LCP a largo plazo para toda la web.

Del sector

• Blog de Cloudflare: Early Hints — el propio artículo de Cloudflare sobre el lanzamiento de 103 Early Hints, incluidos resultados del mundo real y detalles de implementación en el CDN.
• Librería JS web-vitals (GitHub) — la librería canónica para recopilar TTFB (y todas las Web Vitals) de usuarios reales; úsala para enviar el TTFB de campo a tu propia analítica.
• Web Almanac 2022 de HTTP Archive — Rendimiento — línea base histórica que muestra un 40 % de TTFB bueno en móvil bajo el entonces nuevo umbral de 800 ms; útil para el contexto de tendencias plurianuales.
• Fastly — HTTP/2 Server Push vs Early Hints — perspectiva del CDN sobre por qué Early Hints está reemplazando a Server Push para reducir el impacto del TTFB.

Estadísticas que vale la pena citar

• ~42 % de los sitios móviles tienen un TTFB “bueno” — y apenas ha cambiado en cinco años. La tasa de TTFB bueno en móvil del Web Almanac se ha mantenido en torno al 41–42 % durante cinco años de datos: un estancamiento obstinado en toda la web. Fuente
• En sitios con LCP deficiente, el TTFB por sí solo consumió ~2,27 segundos — casi todo el umbral de “LCP bueno” de 2,5 segundos, antes de que se renderizara cualquier contenido. El TTFB es la subparte más grande del LCP en los sitios que no lo superan. Fuente
• 103 Early Hints ofrecieron varios cientos de milisegundos de mejora del LCP en las pruebas de Shopify y Cloudflare — en algunos casos casi un segundo más rápido. Fuente
• La línea de TTFB “bueno” pasó de 500 ms a 800 ms en 2022, y los datos históricos se recalcularon bajo el nuevo estándar — vale la pena saberlo antes de comparar números antiguos de TTFB. Fuente

Ponte a prueba: Time to First Byte

Cinco preguntas rápidas sobre qué mide el TTFB y cómo mejorarlo. Elige una respuesta para cada una y luego comprueba.

Registro de cambios