TTFB (Time to First Byte): qué es, cuánto es aceptable y cómo reducir el tiempo de respuesta de tu servidor

El primer byte es lo primero que se paga en cualquier carga. Si tu servidor tarda en empezar a responder, todo lo que viene después arranca tarde: el TTFB (Time to First Byte) decide a qué hora empieza a existir tu página.

Qué es el TTFB (Time to First Byte) y en qué se va el tiempo

El TTFB mide el tiempo entre el inicio de la navegación y el momento en que empieza a llegar el primer byte de la respuesta. Se calcula de startTime a responseStart en la API de Navigation Timing, y la definición completa está en la guía de Time to First Byte de web.dev.

El error más común es leerlo como "lo que tarda mi servidor". El TTFB es la suma de cinco tramos y solo el último depende de tu backend:

• Redirecciones.
• Arranque del service worker, si existe.
• Resolución DNS.
• Conexión y negociación TLS.
• La petición hasta el primer byte: aquí entra el trabajo del servidor.

Puedes tener un backend rapidísimo con un TTFB malo por DNS, redirecciones o TLS, y también lo contrario: un hosting lento escondido detrás de una red excelente.

El TTFB no es una Core Web Vital (pero condiciona a las que sí lo son)

Las Core Web Vitals son LCP, INP y CLS. El TTFB es una métrica fundacional y diagnóstica que va antes que las métricas de carga, y Google lo dice sin rodeos: no es imprescindible cumplir su umbral "bueno", siempre que no impida rendir bien en las que sí importan. El marco completo está en qué son las Core Web Vitals y cómo afectan al SEO.

El primer byte también incluye las 103 Early Hints

Chrome 115 cambió la medición para contar el inicio de las cabeceras de la respuesta final y lo revirtió en Chrome 133 por incompatibilidad entre herramientas. Con 103 Early Hints activos, el navegador descarga recursos críticos antes de que llegue el HTML, así que el TTFB que ves puede ser más bajo que el trabajo real del servidor: mídelo también por dentro.

Cuánto es aceptable: 0,8 segundos en el percentil 75 (y por qué Lighthouse dice 600 ms)

El umbral oficial: bueno hasta 0,8 s, malo por encima de 1,8 s, en el percentil 75 de las cargas y con móvil y escritorio por separado. El objetivo es que ese mismo percentil tenga un First Contentful Paint bueno, y su umbral es 1,8 s (First Contentful Paint): los 0,8 s del TTFB son el margen que le dejas al navegador para pintar.

De ahí sale la confusión de los 600 ms: la auditoría Reduce server response times de Lighthouse y el insight "Document request latency" de PageSpeed Insights fallan el documento principal por encima de 600 ms. No contradicen los 800 ms: el umbral del TTFB es mayor porque incluye DNS y redirecciones, y la auditoría solo mide el documento final. Y para cerrar la duda más repetida: el TTFB no es un factor de ranking directo.

Cómo medir el TTFB: primero campo, después laboratorio

El orden no es negociable: el campo decide si hay problema, el laboratorio sirve para arreglarlo.

Datos de campo

• CrUX: el TTFB está en BigQuery y en la CrUX API como experimental_time_to_first_byte, con histograma de tres cubos y percentil 75 (documentación de la CrUX API).
• Solo se reporta la petición de navegación principal; los recursos de otros orígenes necesitan Timing-Allow-Origin.
• La API publica también round_trip_time, contexto útil pero no un sustituto del TTFB.
• PageSpeed Insights muestra campo y laboratorio juntos.

Datos de laboratorio

• Lighthouse: da el tiempo del documento principal con límite de 600 ms y excluye DNS y redirecciones, así que subestima el TTFB: es un subconjunto de la métrica.
• PSI, insight Document request latency: avisa si hubo redirecciones y si el servidor pasó de 600 ms.

Por qué campo y laboratorio no coinciden

Si el laboratorio es peor, tu entorno de prueba es más limitado que el del usuario típico. Si el campo es peor, el laboratorio no ve la caché del servidor, las redirecciones ni las diferencias de red: prueba una página poco visitada o un parámetro que evite la caché para ver el TTFB en frío.

El dato que le importa al SEO: Estadísticas de rastreo

El informe Estadísticas de rastreo de Search Console muestra el tiempo de respuesta promedio de todo lo que descarga Googlebot y el estado del host. Su ayuda lo dice literalmente: si tu sitio responde despacio, Googlebot frena sus peticiones para no sobrecargar tu servidor. Un servidor lento no solo se siente lento, también se rastrea menos. Cómo leerlo está en cómo usar Google Search Console para mejorar tu SEO y el lado del servidor en análisis de logs del servidor para SEO.

Medirlo por dentro: la cabecera Server-Timing

Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side rendering";dur=212.2 reparte el TTFB entre base de datos, render en servidor y caché de borde. Se ve en DevTools y se expone en la API PerformanceServerTiming (documentación de MDN). Cuidado: puede exponer detalles internos, no la dejes con datos sensibles en producción.

Por qué tu TTFB es alto: las causas que se repiten

• Hosting: el plan es la primera variable; sin memoria ni CPU, la instancia sirve cada página con esfuerzo.
• Sin caché: cada visita regenera la página y el primer visitante de cada ventana paga toda la latencia.
• Sin CDN: si tus usuarios están lejos del origen, la latencia de ida y vuelta se paga igual.
• Redirecciones en cadena: http a https, con y sin www, barra final, acortadores y campañas.
• DNS y TLS lentos, y HTTP/1.1 donde caben HTTP/2 o HTTP/3.
• Cachés y Early Hints que esconden el problema: medir la portada cacheada no representa al primer visitante.

Cómo bajar el TTFB, de mayor a menor impacto

1. Mide en frío antes de tocar nada: campo (CrUX o PSI) más una URL sin caché.
2. Revisa hosting y recursos: memoria y CPU de la instancia, versiones al día del lenguaje, la base de datos y el servidor.
3. Añade caché de página y de objetos: OPcache, Redis o Memcached, y define qué no se cachea.
4. Sirve desde el borde con una CDN: ojo con los parámetros de analítica, que impiden reutilizar la copia del borde.
5. Elimina las redirecciones que controlas y añade HSTS para que el salto a https no cueste una ida y vuelta.
6. Revisa protocolo, TLS y compresión: HTTP/2 o HTTP/3, TLS 1.3 y brotli, gzip o zstd.
7. Entrega el HTML cuanto antes: streaming del marcado, render en servidor con streaming o generación estática.
8. Usa 103 Early Hints solo si el backend tarda de verdad y sigue midiendo el tiempo de servidor.
9. Recomprueba con los mismos datos de campo y espera semanas: el campo va con retraso.

TTFB y SEO: lo que sí pasa y lo que no

Lo que sí ocurre es que el TTFB alarga el LCP, porque el reloj del LCP arranca en la navegación y el TTFB es su primer tramo: el reparto completo está en cómo medir y mejorar el LCP.

El segundo efecto está documentado y es de rastreo: Google sube el límite de capacidad de rastreo si los tiempos de respuesta (latencia y Time-to-First Byte incluidos) se mantienen o mejoran, y lo baja si el sitio va más lento o responde con 5xx o 429 (gestión del presupuesto de rastreo).

La frase honesta, sin promesas: mejorar el TTFB no es un truco para subir posiciones, es quitar un techo que limita lo que sí puedes mejorar y evitar perder rastreo.

Errores frecuentes al optimizar el TTFB

• Perseguir un objetivo que Google no publica: repetir "TTFB por debajo de 200 ms" sin fuente. El número documentado es 0,8 s en el percentil 75.
• Creer que Lighthouse mide el TTFB completo: excluye DNS y redirecciones.
• Medir solo la portada cacheada o sin separar móvil y escritorio.
• Arreglar el frontend cuando el problema es el servidor.
• Cachear HTML con contenido personalizado y romper la experiencia.
• Olvidar la primera visita: el TTFB de caché caliente no representa al visitante número uno.

Conclusión: la lista de comprobación en seis pasos

1. Mira el percentil 75 en datos de campo, móvil y escritorio separados.
2. Si el campo es peor que el laboratorio, busca caché, redirecciones y red con una URL en frío.
3. Elimina redirecciones y usa HSTS para el salto a HTTPS.
4. Añade caché de página y de objetos y, si tus usuarios están lejos, una CDN.
5. Comprueba protocolo, TLS y compresión.
6. Revisa Estadísticas de rastreo en Search Console: respuesta promedio y estado del host.