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

El Time to First Byte mide cuánto tarda el primer byte de una respuesta en llegar al navegador después de enviarse una solicitud. En los storefronts de comercio renderizados en servidor o en el edge, es la métrica de latencia fundamental: cada Vital posterior, en especial el LCP, se apoya en él. Un TTFB malo no puede compensarse con código del lado del cliente, por ingenioso que sea.

Definición

El TTFB incluye la resolución DNS, los handshakes TCP y TLS, el reenvío de la solicitud a través de cualquier CDN y salto de proxy inverso, el tiempo de renderizado upstream en el origen o en el edge worker, y finalmente el tiempo hasta enviar el primer byte del documento HTML. Se captura mediante la Navigation Timing API y se muestra en herramientas como la librería web-vitals, Lighthouse y la mayoría de las plataformas RUM. Google considera buenos los valores por debajo de 800 ms para solicitudes de navegación, mientras que por debajo de 200 ms es realista para respuestas en caché servidas desde una content-delivery-network-cdn o un edge worker.

Por qué es importante

El TTFB fija el techo del rendimiento percibido. En storefronts headless que ejecutan SSR en Next.js o Remix, el TTFB suele estar dominado por las llamadas upstream a las APIs de comercio, los proveedores de búsqueda y los servicios de personalización. Un renderizado SSR en frío de 600 ms no deja margen para alcanzar un LCP de 2,5 segundos en redes móviles lentas. El TTFB también condiciona las estrategias de SSR en streaming: sin un envío temprano del head del documento, los navegadores no pueden empezar a precargar los recursos críticos. Mejorar el TTFB tiene, por tanto, efectos que se acumulan sobre los Core Web Vitals, la conversion-rate-optimization-cro y el search-engine-optimization-seo.

Casos de uso

Los equipos de storefronts componibles atacan el TTFB cacheando HTML en el edge con ISR o stale-while-revalidate, ubicando los workers de renderizado junto al origen y reduciendo el número de llamadas de API bloqueantes durante el SSR. Los storefronts en Vercel Edge, Cloudflare Workers o Netlify Edge usan fragmentos renderizados en el edge para mantener rápido el contenido dinámico mientras las shells estáticas se transmiten primero. El SSR en streaming se combina con React Server Components para enviar HTML temprano y resolver los datos de producto más tarde. Los equipos monitorizan el TTFB por ruta y por región, y tratan las regresiones en la tasa de aciertos de la capa de caché como incidentes de producción, porque se propagan de inmediato al LCP y a la tasa de rebote.

Relacionado

Explora Performance and Core Web Vitals · Composable Headless Frontend.