TTFB de usuarios reales (datos de campo)

Qué hace esta comprobación

Lee el percentil 75 de Time to First Byte del Chrome User Experience Report — el tiempo desde que el navegador de un usuario real de Chrome envía la petición de navegación hasta que llega el primer byte de la respuesta. CrUX lo agrega en una ventana móvil de 28 días. Es una métrica experimental de CWV, no es una señal de posicionamiento por sí misma, pero limita por arriba a todas las demás métricas de paint: nada más puede renderizarse hasta que llegue el primer byte.

TTFB de campo (p75)	Veredicto
≤ 800 ms	Bueno
800–1.800 ms	Necesita mejorar
> 1.800 ms	Deficiente

TTFB engloba todo lo que pasa entre el usuario y el origen: resolución DNS, handshake TLS, cadenas de redirecciones, encolado de peticiones en tu servidor, trabajo de la aplicación y tiempo dedicado a renderizar plantillas en servidor. Cualquier cosa que ocurra antes de que salga el primer byte suma a este número.

Por qué importa

TTFB no es un Core Web Vital, pero es la restricción aguas arriba de todos ellos. Un TTFB de 2 segundos significa que el LCP no puede bajar de los 2,5 s — solo quedan 500 ms para todo lo demás. Recortar 500 ms de TTFB suele recortar el LCP en una cantidad similar, prácticamente gratis.

También expone problemas que las herramientas de laboratorio no detectan:

• Usuarios lejanos. Un servidor en us-east-1 parece rápido desde una herramienta de laboratorio con base en EE. UU., pero terrible para un usuario brasileño. El TTFB de campo te muestra la realidad geográfica.
• Estados fríos del servidor. Si tu origen ejecuta funciones serverless, la latencia de arranque en frío solo aparece en los datos de usuarios reales; las herramientas de laboratorio precalientan la caché por ti.
• Cadenas de redirecciones. Un 301 de example.com → www.example.com → https://www.example.com/ añade un round-trip completo por salto al TTFB. Las herramientas de laboratorio o se las saltan o las reportan de otra manera.

Cómo mejorarla

1. Pon un CDN delante de tu origen. Incluso para páginas dinámicas, un CDN puede cachear sesiones TLS y estado de conexión. Cloudflare, Fastly, Bunny y Vercel Edge tienen planes gratuitos o casi gratuitos:

# Cloudflare proxy on (orange-clouded) — instant CDN
# nslookup your domain — you should see Cloudflare IPs, not your origin

2. Cachea el HTML en el borde. Para páginas que no necesitan ser por usuario (marketing, blog, documentación), pon Cache-Control: s-maxage=86400, stale-while-revalidate=604800 para que el CDN devuelva el HTML cacheado en <50 ms:

Cache-Control: public, s-maxage=86400, stale-while-revalidate=604800

La directiva stale-while-revalidate permite al CDN servir al instante una respuesta caducada mientras la revalida en segundo plano — lo mejor de ambos mundos.

3. Elimina las cadenas de redirecciones. Audita con curl:

curl -sIL https://example.com/ | grep -E "^(HTTP|Location)"

Cada línea Location: es un round-trip extra. Infractores habituales: http→https, apex→www (o www→apex) y diferencias de barra final. Reduce esto a un único 301 cuando sea posible.

4. Perfila tu servidor con Server-Timing. Añade cabeceras de respuesta que le digan a DevTools dónde se ha ido el tiempo:

// Ejemplo en Express/Node
res.setHeader("Server-Timing", "db;dur=120, render;dur=45, total;dur=170");

La pestaña Network de Chrome mostrará un desglose por fase para que veas si el tiempo se va en consultas a la base de datos, renderizado de plantillas o sobrecarga del framework.

5. Usa HTTP/2 o HTTP/3. El slow-start de TCP y el head-of-line blocking de HTTP/1.1 cuestan TTFB real. Todos los CDN modernos vienen por defecto con HTTP/2; muchos ya sirven HTTP/3 (QUIC) para un rendimiento aún mejor en redes móviles.

6. Recorta la distancia al origen. Si tienes un origen en una única región y usuarios globales, plantéate replicarlo o migrar a un framework con renderizado en el borde (Astro, Next.js sobre Vercel, SvelteKit sobre Cloudflare Workers).

Preguntas frecuentes

Mi TTFB es rápido en mi máquina de desarrollo pero lento en CrUX. ¿Por qué?

Estás coubicado con tu origen; tus usuarios reales no. Añade un CDN y tus usuarios globales verán un TTFB más cercano al de tu experiencia de desarrollo. La otra causa habitual es la latencia de arranque en frío en despliegues serverless — tu primera petición tras un rato de inactividad paga una penalización de 500–2.000 ms.

¿Debo preocuparme por el TTFB si en CrUX está etiquetado como «experimental»?

Sí. Es experimental en el sentido de que Google aún no lo ha convertido en un Core Web Vital formal, pero el valor está bien definido y los umbrales son estables. Trátalo como un indicador adelantado de tu LCP — si el TTFB es deficiente, el LCP casi seguro lo será también.

Mi TTFB es bueno pero el LCP es deficiente. ¿Qué pasa?

El cuello de botella está aguas abajo: renderizado, carga de imágenes o recursos que bloquean el renderizado. Mira a continuación la regla del LCP. Un TTFB de campo bueno + LCP bueno significa que tu servidor es rápido y la lentitud está en el cliente; TTFB de campo deficiente + LCP deficiente significa que arregles primero el TTFB, porque cada mejora ahí se traduce en mejoras del LCP gratis.