Qu'est-ce que le Time to First Byte (TTFB) ?

Le Time to First Byte mesure le temps que met le premier octet d'une réponse à atteindre le navigateur après l'envoi d'une requête. Pour les boutiques de commerce rendues côté serveur ou à l'edge, c'est la métrique de latence fondamentale : chaque Vital en aval, en particulier le LCP, repose dessus. Un mauvais TTFB ne peut pas être rattrapé par du code côté client astucieux.

Définition

Le TTFB inclut la résolution DNS, les handshakes TCP et TLS, le transfert de la requête à travers tout CDN et tous les sauts de reverse-proxy, le temps de rendu amont à l'origine ou au worker edge, et enfin le temps de vidage du premier octet du document HTML. Il est capturé via l'API Navigation Timing et exposé dans des outils comme la bibliothèque web-vitals, Lighthouse et la plupart des plateformes RUM. Google considère les valeurs sous 800 ms comme bonnes pour les requêtes de navigation, tandis que sous 200 ms est réaliste pour des réponses mises en cache servies depuis un content-delivery-network-cdn ou un worker edge.

Pourquoi c'est important

Le TTFB fixe le plafond de la performance perçue. Dans les boutiques headless exécutant du SSR sur Next.js ou Remix, le TTFB est souvent dominé par les appels amont aux API commerce, aux fournisseurs de recherche et aux services de personnalisation. Un rendu SSR à froid de 600 ms ne laisse aucun budget pour atteindre un LCP de 2,5 secondes sur des réseaux mobiles lents. Le TTFB conditionne aussi les stratégies de streaming SSR : sans vidage précoce de l'en-tête du document, les navigateurs ne peuvent pas commencer à précharger les ressources critiques. Améliorer le TTFB a donc des effets cumulatifs sur les Core Web Vitals, la conversion-rate-optimization-cro et le search-engine-optimization-seo.

Cas d'usage

Les équipes de boutique composable attaquent le TTFB en mettant en cache le HTML à l'edge avec l'ISR ou le stale-while-revalidate, en colocalisant les workers de rendu avec l'origine et en réduisant le nombre d'appels API bloquants pendant le SSR. Les boutiques sur Vercel Edge, Cloudflare Workers ou Netlify Edge utilisent des fragments rendus à l'edge pour garder le contenu dynamique rapide pendant que les shells statiques streament en premier. Le streaming SSR est associé aux React Server Components pour vider le HTML tôt et résoudre les données produit plus tard. Les équipes surveillent le TTFB par route et par région, et traitent les régressions du taux de hit de la couche de cache comme des incidents de production car elles se propagent immédiatement au LCP et au taux de rebond.

Voir aussi

Découvrez Performance and Core Web Vitals · Composable Headless Frontend.