Tiempo hasta el primer byte (TTFB): el reloj que corre antes de que tu página llegue
El tiempo hasta el primer byte es el reloj que arranca en el instante en que un visitante hace clic en tu enlace y se detiene cuando llega el primer byte de tu HTML — y como ocurre antes de que algo sea visible, toda métrica de carga posterior tiene que esperar por él. La guía de Google es rotunda: el TTFB precede a toda otra métrica de carga significativa, así que un primer byte lento pone tope a lo rápido que tu página puede llegar a ser. Si tu servidor tarda 1,2 segundos en responder, tu Largest Contentful Paint no puede bajar de 1,2 segundos sin importar lo perfecto que hayas comprimido las imágenes o diferido el JavaScript — no puedes optimizar más allá de un servidor lento. El umbral a aprobar es 0,8 segundos, con cualquier cosa por encima de 1,8 contada como mala, pero eso es un piso donde el TTFB ya te está dañando, no una meta; los sitios competitivos apuntan a menos de 200 milisegundos. Es un compuesto que diagnosticas, no una sola cosa que arreglas — DNS, los handshakes de TCP y TLS, el viaje de red, y el propio tiempo de procesamiento del servidor — y los arreglos son todos del lado del servidor, en orden de prioridad: hosting, una CDN, caché, quitar redirecciones, y cómo se genera el HTML. Aquí los números cuentan la historia: una página estática desde un borde de CDN responde en 80-150ms porque no hay consulta a base de datos ni cómputo por visitante entre el clic y el primer byte — aprueba el umbral el día uno, donde un sitio con base de datos tiene que ganárselo.
¿Qué mide exactamente el TTFB?
El tiempo hasta el primer byte mide el tiempo transcurrido entre empezar a navegar hacia una página y cuando el primer byte de la respuesta empieza a llegar (web.dev, 2026). No es tanto un solo número como una suma de etapas: una búsqueda de DNS para resolver el nombre del host, la conexión TCP y el handshake TLS para HTTPS, el propio tiempo del servidor procesando la petición y generando la respuesta, y el viaje de red de ida y vuelta que trae ese primer byte de regreso (Is It Down Checker, 2026). Cada etapa puede frenarse de forma independiente, que es por qué el TTFB es una métrica que diagnosticas en vez de un interruptor que accionas.
Distintas herramientas lo nombran distinto —Lighthouse lo llama “tiempo de respuesta del servidor”, Chrome DevTools lo llama “esperando la respuesta del servidor”— pero el papel foundational es el mismo (DebugBear, 2026). Para una petición de navegación, la petición del documento HTML mismo, el TTFB precede a toda otra métrica de rendimiento de carga significativa (web.dev, 2026). Es, muy literalmente, lo primero que pasa cuando una página carga, y lo único detrás de lo cual todo lo demás espera.
¿Qué es un buen TTFB?
La guía aproximada de Google pone el buen TTFB en 0,8 segundos o menos, necesita-mejorar entre 0,8 y 1,8 segundos, y malo por encima de 1,8 segundos (web.dev, 2026). Pero esa cifra de 0,8 segundos se entiende mejor como un piso más que una meta — es el punto donde el TTFB ya está dañando tus Core Web Vitals, y para un camino cómodo a un buen Largest Contentful Paint en el percentil 75, deberías apuntar a menos de 200 milisegundos (PaidHosting, 2026).
Hay una sutileza de medición que vale conocer: la auditoría de “tiempo de respuesta del servidor” de Lighthouse usa un umbral más estricto de 600ms porque mide solo la porción de procesamiento del servidor, no el TTFB completo incluyendo el establecimiento de conexión (OuterBox, 2026). Cualquiera sea la herramienta que uses, más bajo siempre es mejor, y la brecha entre un primer byte de 150ms y uno de 900ms la siente directamente cada visitante.
¿Por qué un número lento arruina todo lo que sigue?
Porque el TTFB es foundational: cualquier tiempo sumado a él también se suma al Largest Contentful Paint y al First Contentful Paint (corewebvitals.io, 2026). El mecanismo es simple. El elemento LCP —normalmente tu imagen principal o titular— no puede empezar a cargar hasta que el navegador recibió el HTML que lo referencia, y ese HTML no llega hasta que el TTFB termina, así que un TTFB de 600ms significa que el LCP no puede empezar antes de 600ms (PaidHosting, 2026).
Esta es la idea que la mayoría del consejo de rendimiento de frontend se pierde: no puedes optimizar más allá de tu TTFB. Comprimir imágenes, diferir JavaScript y minificar CSS reducen todos el tiempo después de que llega el primer byte, pero ninguno puede reducir el tiempo antes de él — si tu TTFB es 1,2 segundos, tu LCP no puede ser más rápido que 1,2 segundos sin importar lo optimizadas que estén tus imágenes (PaidHosting, 2026). Un TTFB de 100ms deja 2,4 segundos de presupuesto para alcanzar el umbral de LCP de 2,5 segundos de Google; uno de 900ms deja 1,6. Arregla el primer byte primero, luego el frontend — que es por qué esto está aguas arriba de las métricas de carga de nuestro pilar sobre Core Web Vitals y velocidad web.
La escalera de referencia realista
Los umbrales abstractos importan menos que los números concretos, y el TTFB rastrea la infraestructura lo bastante de cerca como para tabularse (Is It Down Checker, 2026):
| Montaje | TTFB típico |
|---|---|
| Página estática desde un borde de CDN cerca del usuario | 80-150ms (el piso) |
| Página dinámica con base de datos, origen bien ajustado | 200-400ms |
| Blog de WordPress en la misma región | 300-700ms |
| Página con base de datos, transcontinental | 500-1.500ms |
| Consultas de base de datos frías, varias llamadas a API, sin caché | 1.500-5.000ms |
El patrón es inconfundible: el TTFB sube con la cantidad de trabajo que el servidor hace por petición. Un archivo estático cacheado no necesita casi nada; una página armada desde consultas a base de datos y llamadas a API en cada visita necesita muchísimo (DebugBear, 2026). La escalera es en realidad una escalera de cómputo por petición.
¿Qué causa un primer byte lento?
El TTFB lento viene de cualquiera de las capas de la cadena, que es por qué el diagnóstico importa más que un arreglo reflejo (OuterBox, 2026). El contribuyente más grande suele ser el tiempo de procesamiento del servidor — las búsquedas en base de datos, el renderizado del framework y la sobrecarga de plugins necesarios para generar una página que no estaba cacheada (web.dev, 2026). La distancia física es lo siguiente e inevitable: la luz viaja por fibra a cerca de 200.000 km por segundo, así que una petición de Nueva York a un servidor en Los Ángeles carga un viaje mínimo que ningún ajuste puede quitar (InMotion, 2026).
Dos causas más sutiles muerden con frecuencia. Las redirecciones suman cada una un viaje de ida y vuelta, y las cadenas de redirección se acumulan — un problema particular para el tráfico que llega por redirecciones de analítica desde anuncios y boletines (web.dev, 2026). Y las llamadas a API externas hechas mientras se construye el HTML inicial anidan el propio TTFB del tercero dentro del tuyo, así que un servicio socio lento se vuelve tu primer byte lento (DebugBear, 2026). Un TTFB alto es una señal para investigar por qué el navegador está esperando, no una receta para una sola herramienta.
¿Cómo lo arreglas, del lado del servidor y en orden?
Como el TTFB se decide antes de que el navegador reciba nada, los arreglos son todos del lado del servidor, y se ordenan limpio por impacto: hosting, luego una CDN, luego caché, luego redirecciones, luego cómo se genera el HTML (Logos Web Designs, 2026). El mejor hosting va primero porque cada paso de compartido a VPS a dedicado suele reducir el TTFB a la mitad, y una CDN va después porque sirve el contenido desde un borde cerca del usuario y puede cachear el HTML para que el origen nunca sea contactado (Is It Down Checker, 2026; web.dev, 2026).
El caché reduce el trabajo que el servidor repite por cada visitante, aunque las páginas de carrito, checkout y personalizadas muchas veces no pueden cachearse igual que una plantilla estática (OuterBox, 2026). Varias ganancias a nivel de conexión se acumulan encima: TLS 1.3 corta el handshake de dos viajes a uno, HTTP/3 con QUIC combina más el establecimiento de conexión, la compresión Brotli encoge la respuesta, y un proveedor de DNS rápido resuelve en menos de 20ms (gf.dev, 2026). Lo que no ayudará es ningún truco de frontend — la decisión se toma antes de que el navegador reciba una cosa, que es por qué nuestras guías sobre qué es una CDN y el caché web hacen más por el TTFB que cualquier cantidad de trabajo en imágenes.
Cómo medirlo bien
Mide con datos de campo primero, porque reflejan usuarios reales e incluyen retrasos como las redirecciones que las herramientas de laboratorio se pierden (web.dev, 2026). PageSpeed Insights muestra el TTFB de usuarios reales del Informe de Experiencia de Usuario de Chrome en la parte superior de su informe, y Google Search Console marca los primeros bytes lentos como “los tiempos de respuesta del servidor son lentos” junto a tus otros Core Web Vitals (PaidHosting, 2026). Para una sola carga de prueba, el panel de Red de Chrome DevTools y WebPageTest ambos lo muestran.
Dos hábitos separan un diagnóstico real de uno engañoso. Prueba respuestas cacheadas y no cacheadas —añade una cadena de consulta aleatoria para saltar el caché de la CDN y medir el tiempo real de origen— y prueba a distintas horas del día, ya que un servidor que responde en 100ms a las 3am y 900ms a las 3pm tiene un problema de capacidad (gf.dev, 2026). Y lee la distribución del percentil 75 en vez de la media, porque un TTFB promedio de 180ms puede esconder un percentil 75 de 900ms por consultas lentas ocasionales o picos de tráfico — y el percentil 75 es justo lo que Google mide (PaidHosting, 2026).
Por qué un sitio estático aprueba el umbral el día uno
Todo lo de arriba apunta a la misma respuesta estructural. Como el TTFB está dominado por el trabajo del servidor por petición, y un sitio estático pre-construye su HTML durante el despliegue, no hay consulta a base de datos, ni renderizado de plantilla, ni cómputo por visitante entre el clic y el primer byte — la CDN simplemente entrega un archivo que ya sostiene en un nodo de borde cerca del usuario. Eso produce un TTFB en el rango de 80-150ms, el piso de la escalera, y aprueba el umbral de 0,8 segundos de Google por defecto mientras un CMS con base de datos tiene que pelearlo (Logos Web Designs, 2026).
La ganancia se acumula, porque un primer byte rápido es un presupuesto de LCP más grande gratis. Cuando el HTML llega en 120ms en vez de 900, el navegador tiene casi la ventana completa de 2,5 segundos para cargar y pintar el contenido principal, que es por qué la entrega estática tiende a cargar un buen LCP e INP junto con ella (Logos Web Designs, 2026). Es la misma arquitectura que vuelve el sitio barato de alojar y trivial de servir desde una CDN — una decisión, rindiendo en la métrica que condiciona a todas las demás.
Las salvedades honestas: el TTFB es un diagnóstico, no un veredicto
Dos límites honestos evitan que esto se vuelva un eslogan. Primero, un TTFB fuerte no garantiza buenos Core Web Vitals — una página puede entregar su primer byte rápido y aun así fallar el Largest Contentful Paint si la imagen LCP se carga con lazy load, el contenido principal depende de JavaScript, el CSS bloquea el renderizado, o una fuente web retrasa el texto (OuterBox, 2026). El TTFB despeja la pista; el frontend todavía tiene que volar el avión, que es por qué los recursos que bloquean el renderizado importan incluso en un servidor rápido.
Segundo, lo inverso también aplica: una página con un TTFB mediocre puede aun así entregar una experiencia aceptable si el resto de la ruta crítica es liviana, así que el TTFB se usa mejor como una señal de diagnóstico dentro del cuadro más grande en vez de un veredicto de aprobado-o-reprobado (OuterBox, 2026). Pero la dirección nunca está en duda: un primer byte lento solo puede dañar, uno rápido solo puede ayudar, y el primer byte más rápido de todos es el que tu servidor nunca tuvo que computar. Ese es el mismo principio que recorre toda la cornerstone de rendimiento — el trabajo más rápido es el que diseñaste para no hacer.
Frequently asked
- ¿Qué es un buen tiempo hasta el primer byte?
- La guía aproximada de Google marca un TTFB de 0,8 segundos (800 milisegundos) o menos como 'bueno', de 800ms a 1,8 segundos como 'necesita mejorar', y cualquier cosa por encima de 1,8 segundos como 'malo'. Pero 0,8 segundos es un piso —el punto en que el TTFB ya está dañando tus Core Web Vitals— no una meta. Para un camino cómodo a un buen Largest Contentful Paint, los sitios competitivos apuntan a menos de 200 milisegundos. Como referencia, una página estática servida desde un borde de CDN cercano responde en cerca de 80-150ms, mientras que una página dinámica con base de datos suele caer en 200-400ms y una sin caché mucho más alto.
- ¿El TTFB es un factor de posicionamiento de Google?
- No de forma directa — el TTFB no es uno de los Core Web Vitals que Google puntúa, así que no hay penalización de posicionamiento atada a la métrica en sí. Pero alimenta el Largest Contentful Paint, que sí es una señal de posicionamiento, y un TTFB lento hace casi imposible lograr un buen LCP. Si tu servidor tarda un segundo en enviar el primer byte, el LCP no puede dispararse antes de ese segundo, sin importar lo optimizado que esté tu frontend. Así que el TTFB afecta el posicionamiento de forma indirecta, a través de las métricas de carga que condiciona, y Google ha confirmado que el tiempo de respuesta del servidor afecta el posicionamiento.
- ¿Cómo reduzco mi TTFB?
- El TTFB se decide del lado del servidor, así que los arreglos de frontend como comprimir imágenes o diferir JavaScript no ayudan — esos solo afectan el tiempo después de que llega el primer byte. Las cinco palancas más grandes, en orden de prioridad, son: mejor hosting (cada paso de compartido a VPS a dedicado suele reducir el TTFB a la mitad), una CDN para servir el contenido desde un borde cerca del usuario, caché para que el servidor no regenere las páginas por petición, quitar las redirecciones, y cambiar cómo se genera el HTML — muchas veces pasando a salida estática pre-construida. Empieza por diagnosticar qué capa posee el retraso antes de cambiar nada.
- ¿Por qué mi TTFB afecta mi puntuación de LCP?
- Porque el TTFB es foundational — precede a toda otra métrica de carga, así que cualquier tiempo esperando el primer byte es tiempo sumado al Largest Contentful Paint y al First Contentful Paint. El elemento LCP, normalmente tu imagen principal o titular, no puede empezar a cargar hasta que el navegador recibió el HTML que lo referencia, y ese HTML no llega hasta que el TTFB termina. Un TTFB de 600ms significa que el LCP no puede empezar antes de 600ms, dejando un presupuesto ajustado para alcanzar el umbral 'bueno' de 2,5 segundos de Google. No puedes optimizar más allá de un servidor lento.
- ¿Por qué los sitios estáticos tienen un TTFB tan bajo?
- Porque el TTFB está dominado por el trabajo que el servidor hace por petición, y un sitio estático hace casi ninguno. Su HTML está pre-construido durante el despliegue, así que cuando llega un visitante no hay consulta a base de datos, ni renderizado de plantilla, ni cómputo por visitante entre el clic y el primer byte — una CDN simplemente entrega un archivo que ya tiene, cacheado en un nodo de borde cerca del usuario. Eso produce un TTFB en el rango de 80-150ms, aprobando el umbral de 0,8 segundos de Google el día uno, mientras que un CMS con base de datos tiene que pelearlo con capas de caché y ajuste del servidor.