Guides

Le TTFB, ou Time To First Byte, est le temps qui s'écoule entre le moment où votre navigateur demande une page à un serveur et le moment où le premier octet de la réponse revient. Il se mesure en millisecondes et couvre tout ce qui doit se produire avant que le navigateur ne puisse même commencer à lire la page : la résolution du domaine, l'ouverture de la connexion et - la partie qui domine généralement - le serveur qui effectue son travail et envoie ce premier octet.

Il compte parce que le TTFB est la taxe payée sur chaque requête avant que quoi que ce soit de visible ne puisse se produire. Un navigateur ne peut afficher un seul pixel tant que les octets ne commencent pas à arriver ; un TTFB lent retarde donc l'ensemble de la page d'autant, quelle que soit la qualité de l'optimisation de vos images, de votre CSS et de votre JavaScript. C'est le plancher de votre vitesse de chargement.

Ce que le TTFB mesure vraiment

Sous le capot, le TTFB est la somme de plusieurs attentes plus petites : les éventuelles redirections, la résolution DNS qui transforme votre domaine en adresse IP, la connexion TCP et la négociation TLS qui la sécurise, le temps que la requête met à voyager vers le serveur, et enfin le temps de traitement du serveur jusqu'à ce que le premier octet soit renvoyé. Sur la plupart des sites, cette dernière partie - le temps que met le serveur à construire la réponse - est la plus importante et la plus facile à corriger.

Point crucial : le TTFB est une mesure back-end et réseau, pas front-end. Si votre TTFB est élevé, le problème se situe au niveau du serveur, de l'hébergement ou du chemin réseau, pas dans votre code React ou Vue. C'est un diagnostic utile : il vous indique de regarder du côté de votre hébergeur, de votre cache et de votre base de données plutôt que de la taille de votre bundle.

Ce qui compte comme un bon TTFB

Les recommandations de Google, publiées sur web.dev, sont qu'un bon TTFB se situe grosso modo sous 800 millisecondes pour la plupart des sites, tout ce qui dépasse 1.8 s étant considéré comme mauvais. Ce sont des seuils de terrain - mesurés sur de vraies visites - ils tiennent donc déjà compte des réseaux et des appareils réels plutôt que d'un test en laboratoire sur du matériel rapide.

• Un hébergement lent ou surchargé - un serveur mutualisé peinant sous le trafic d'autres sites
• Des pages dynamiques non mises en cache, régénérées de zéro à chaque requête
• Des requêtes de base de données lourdes ou un code back-end lent qui gonflent le temps de traitement serveur
• Aucun CDN, si bien que chaque visiteur se connecte à un unique serveur d'origine distant
• Des chaînes de redirection qui ajoutent des allers-retours supplémentaires avant que la vraie réponse ne commence
• Des négociations TLS lentes ou un serveur situé loin de la majeure partie de votre audience

Le TTFB n'est pas lui-même l'un des trois Core Web Vitals, mais il alimente directement le Largest Contentful Paint. Le LCP ne peut jamais être plus rapide que le TTFB qui le précède, car le contenu principal ne peut pas apparaître tant que la réponse n'a pas commencé. Améliorer un TTFB lent améliore souvent le LCP sans effort supplémentaire, et c'est pourquoi le travail de performance commence si souvent ici.

Comment réduire le TTFB

Le plus grand levier côté serveur est le cache. Servir une page depuis un cache de page complète ou un cache en périphérie d'un CDN évite le travail de la régénérer à chaque requête, transformant des centaines de millisecondes de traitement en une réponse quasi instantanée. Au-delà, un hébergement plus rapide ou moins saturé, un code back-end plus léger et l'élagage des requêtes de base de données lentes réduisent tous directement la part de traitement.

Côté réseau, un CDN raccourcit la distance physique entre votre serveur et chaque visiteur, si bien que la requête et la réponse parcourent moins de chemin. Une gestion moderne des connexions - HTTP/2 ou HTTP/3, keep-alive et une configuration TLS bien réglée - réduit la surcharge de négociation, et là où une page peut être pré-rendue en fichiers statiques, l'hébergement statique retire presque entièrement le traitement serveur du chemin critique.

En résumé

En bref, le TTFB est la taxe de réponse serveur sur chaque page que vous servez, et il fixe le plafond de la rapidité que peut ressentir le reste de votre site. Un hébergeur performant, un cache agressif et un CDN sont les trois leviers qui l'améliorent le plus - c'est pourquoi corriger le TTFB est généralement le travail de performance au plus fort effet de levier que vous puissiez réaliser avant de toucher une seule ligne de code front-end.