Time to First Byte (TTFB): definición, causas y cómo reducirlo

¿Qué es Time to First Byte (TTFB)?

Time to First Byte (TTFB), o tiempo hasta el primer byte, es el tiempo entre el inicio de una navegación y el momento en que llega al navegador el primer byte de la respuesta. Incluye redirecciones, el arranque del service worker, la resolución DNS, la conexión y el handshake TLS, la petición y el tiempo de procesamiento del servidor. Hasta entonces no se puede renderizar nada.

TTFB no es una Core Web Vital, pero va antes de First Contentful Paint y Largest Contentful Paint, de modo que una respuesta lenta deja menos margen del LCP para todo lo demás. La definición de referencia está en la guía de TTFB de web.dev (en inglés).

De qué se compone el TTFB

El procesamiento del servidor suele ser la parte que más controlas. La distancia al servidor (la latencia de red) es la parte que mejora una CDN.

Umbrales de TTFB

Google lo evalúa en el percentil 75 de cargas reales de página. web.dev presenta 0,8 segundos como una guía aproximada, no una regla estricta. Una página renderizada en el servidor con un TTFB mayor puede tener un buen LCP, mientras que una aplicación renderizada en el cliente depende más de una respuesta rápida.

Un ejemplo con números

Con cifras ilustrativas, la página de producto de una tienda muestra 120 ms entre DNS, conexión y TLS, y 40 ms para que la respuesta vuelva, pero el servidor tarda 900 ms en construir el HTML porque ejecuta 30 consultas a la base de datos en serie. El TTFB queda en cerca de 1,06 s y el LCP no puede ser mejor. Cachear el HTML renderizado en el edge durante un rato, o reducir las consultas a unas pocas indexadas, elimina casi todos esos 900 ms. La parte de red apenas cambia. Por eso conviene dividir el TTFB en fases antes de optimizar.

Cómo medir el TTFB

En el navegador, la Navigation Timing API lo informa directamente. responseStart se mide desde el inicio de la navegación, así que ya incluye redirecciones, DNS y handshake:

new PerformanceObserver((list) => {
  const [nav] = list.getEntriesByType('navigation');
  console.log('TTFB:', nav.responseStart, 'ms');
}).observe({ type: 'navigation', buffered: true });

Desde la línea de comandos, curl muestra cada fase. time_starttransfer es el tiempo desde el inicio hasta recibir el primer byte:

curl -o /dev/null -s -w "dns: %{time_namelookup}s\nconnect: %{time_connect}s\ntls: %{time_appconnect}s\nttfb: %{time_starttransfer}s\ntotal: %{time_total}s\n" https://example.com

También puedes usar el test de velocidad web de LoadFocus o consultar datos de usuarios reales con el verificador de Core Web Vitals. Las herramientas de laboratorio muestran una carga desde un lugar. Los datos de campo de real user monitoring o del Chrome UX Report muestran lo que reciben realmente tus visitantes, redirecciones incluidas.

Cómo reducir el TTFB

• Servir páginas cacheables desde una CDN. Una red de distribución de contenidos responde desde un servidor edge cercano al visitante, con cabeceras Cache-Control correctas. Las páginas personalizadas no se pueden cachear así.
• Eliminar redirecciones. Corrige los enlaces que pasan de http a https, por un www ausente o por una barra final. Cada una cuesta un viaje de ida y vuelta.
• Acelerar el backend. Añade índices a la base de datos, elimina las consultas N+1, cachea resultados costosos y evita bloquearte con llamadas lentas a terceros.
• Enviar en streaming o prerrenderizar. Envía el HTML por partes mientras se genera, o construye páginas estáticas en el despliegue cuando no necesiten personalización.
• Usar 103 Early Hints. El navegador puede empezar a pedir recursos críticos mientras un backend lento termina la respuesta.
• Medir el backend con Server-Timing. La cabecera expone, por petición, el tiempo de base de datos, de renderizado y de fallos de caché.

Errores comunes

• Medir solo la respuesta cacheada. La caché y Early Hints pueden ocultar un origen lento. Prueba una URL sin caché para ver el tiempo real del servidor.
• Usar responseStart - requestStart como "TTFB". Deja fuera redirecciones, DNS y handshake, y subestima lo que espera el usuario.
• Juzgar por una sola prueba de laboratorio. El TTFB varía con la ubicación y la carga. Mira el percentil 75 de muchas visitas.
• Ignorar los arranques en frío. Una función serverless o un contenedor inactivo pueden retrasar mucho la primera petición tras un periodo tranquilo.
• Dar por bueno el TTFB bajo carga. Una página que responde en 300 ms a un visitante puede tardar segundos cuando llegan cientos a la vez.

TTFB, pruebas de carga y monitorización

Como el procesamiento del servidor es la parte variable, el TTFB es sensible al tráfico. Las pruebas de carga de LoadFocus lanzan tu sitio o API desde más de 25 regiones en la nube y muestran los tiempos de respuesta al subir los usuarios concurrentes, para ver si el backend se degrada antes de que llegue el tráfico real. Page Speed Monitoring repite auditorías de Lighthouse de forma programada desde 25 regiones, de modo que un empeoramiento del TTFB tras un despliegue aparece como tendencia. Para una rutina de monitorización con Core Web Vitals, lee (en inglés) how to monitor Core Web Vitals with alerts and reports.

Preguntas frecuentes sobre TTFB

¿Qué es un buen TTFB?

0,8 segundos o menos en el percentil 75 se considera bueno, y más de 1,8 segundos, malo. Toma 0,8 s como guía aproximada: lo que importa al final es que FCP y LCP sean buenos para tus visitantes.

¿Es TTFB una Core Web Vital?

No. Las Core Web Vitals son LCP, INP y CLS. TTFB es una métrica de diagnóstico que explica parte de un LCP o FCP lento.

¿Cómo mejora una CDN el TTFB?

Responde a las peticiones cacheables desde un servidor edge cercano al visitante, lo que acorta la conexión y evita el viaje al origen. No ayuda con respuestas que se generan por usuario, salvo que la CDN pueda cachearlas o ejecutar la lógica en el edge.

¿Por qué el TTFB difiere entre herramientas de laboratorio y datos de campo?

Una herramienta de laboratorio mide una carga desde una ubicación con una red fija. Los datos de campo incluyen visitantes reales, con sus redirecciones, dispositivos y distancia a tus servidores, por eso rara vez coinciden.

¿Qué diferencia hay entre TTFB y tiempo de respuesta del servidor?

El tiempo de respuesta del servidor cubre solo el trabajo del backend. El TTFB incluye además redirecciones, DNS, conexión, TLS y el trayecto de red, y para visitantes lejanos puede ser mucho mayor.