TTFB (Time To First Byte)
Le TTFB (Time To First Byte, délai avant le premier octet) mesure le temps écoulé entre le moment où le navigateur commence à naviguer vers une page et celui où le premier octet de la réponse lui parvient. Il additionne les redirections, la résolution DNS, l'établissement de la connexion TCP et TLS, puis le temps que met le serveur à produire les premiers octets du HTML. Google recommande un TTFB de 0,8 seconde au plus. Il ne fait pas partie des Core Web Vitals, mais il précède toutes les autres mesures de chargement : un TTFB élevé rend un bon LCP difficile, voire impossible.
Définition détaillée du TTFB
Le TTFB est une mesure de réactivité de la chaîne qui relie le visiteur au serveur. Dans la définition qu'en donne web.dev, le site de Google consacré aux performances web, il correspond au temps entre le début de la navigation (startTime) et le début de la réponse (responseStart) dans l'API Navigation Timing des navigateurs. Il se décompose en cinq phases successives :
- les redirections, s'il y en a, chacune ajoutant un aller-retour complet ;
- le démarrage du service worker, quand la page en utilise un ;
- la résolution DNS, qui traduit le nom de domaine en adresse IP ;
- l'établissement de la connexion TCP et la négociation TLS, pour une page en HTTPS ;
- la requête elle-même, jusqu'à l'arrivée du premier octet de la réponse, ce qui inclut le temps de traitement du serveur : exécution du code, requêtes à la base de données, génération du HTML.
Le TTFB n'est donc pas le « temps de réponse du serveur » au sens strict : il englobe la latence réseau et les redirections, que le serveur ne contrôle pas. C'est une nuance qui compte au moment de lire les outils, dont certains mesurent l'un et d'autres l'autre.
Un point de vocabulaire, apparu avec les réponses 103 Early Hints : ces en-têtes anticipés, envoyés avant la réponse définitive, comptent comme premiers octets. Chrome avait changé la mesure à partir de sa version 115 pour ne compter que la réponse finale, puis est revenu en arrière dans Chrome 133 pour rester compatible avec les outils existants. Le TTFB mesure donc bien le premier octet reçu, quel qu'il soit, et un site qui envoie tôt ses en-têtes ou son <head> affiche un TTFB plus court sans que son serveur soit plus rapide.
Quel est un bon TTFB
Web.dev fixe deux seuils : un TTFB est bon jusqu'à 0,8 seconde et mauvais au-delà de 1,8 seconde, l'intervalle entre les deux étant « à améliorer ». Comme pour les Core Web Vitals, la valeur à regarder est celle du 75e centile des visites : trois visiteurs sur quatre doivent être sous le seuil.
Google présente ce seuil comme un repère approximatif, et non comme une exigence, pour deux raisons. La première : le TTFB n'est pas un Core Web Vital, il n'est donc pas indispensable de passer sous 0,8 seconde tant que cela n'empêche pas d'obtenir de bons résultats sur les mesures qui comptent. La seconde : la bonne valeur dépend de l'architecture du site. Une application monopage qui livre un HTML presque vide, puis le remplit en JavaScript, a besoin du TTFB le plus bas possible, puisque rien ne s'affiche avant que le code s'exécute. Un site rendu côté serveur peut avoir un TTFB plus élevé, parce qu'il fait plus de travail avant d'envoyer, et pourtant afficher son contenu plus tôt, avec un meilleur FCP (First Contentful Paint) et un meilleur LCP.
TTFB et LCP : pourquoi il compte pour le SEO
Le TTFB n'est pas un signal de classement en soi. Son importance vient de sa place dans la chaîne : rien ne peut se passer côté navigateur avant que le premier octet arrive. Web.dev décompose le LCP (Largest Contentful Paint), qui est un Core Web Vital, en quatre sous-parties qui s'additionnent sans recouvrement : le TTFB, le délai de chargement de la ressource principale, la durée de ce chargement, et le délai de rendu de l'élément. Sur une page bien optimisée, le TTFB représente environ 40 % du LCP, les deux délais devant tendre vers zéro. Avec un seuil de LCP à 2,5 secondes, un TTFB de 1,8 seconde ne laisse que 0,7 seconde pour tout le reste ; web.dev écrit qu'un TTFB élevé peut rendre un LCP de 2,5 secondes « difficile, voire impossible » à atteindre.
Les Core Web Vitals entrent dans les systèmes de classement de Google au titre de l'expérience sur la page, et sont mesurés sur les visiteurs réels de Chrome. Un TTFB dégradé se paie donc deux fois : directement, par un LCP qui bascule dans le rouge, et indirectement, par un visiteur qui attend devant une page blanche. Pour l'exploration, l'effet est distinct mais réel : Google a rappelé le 24 novembre 2023 que Googlebot ralentit automatiquement son exploration quand le temps de réponse d'un site augmente de façon significative, au même titre que lorsqu'il rencontre des erreurs serveur. Un serveur lent est donc aussi un serveur moins exploré.
Comment mesurer le TTFB
Web.dev recommande de partir des données de terrain, mesurées sur les vrais visiteurs, parce qu'elles seules incluent les redirections et la diversité des réseaux et des localisations ; les outils de laboratoire testent en général l'URL finale, depuis un point unique, et manquent une partie du délai.
- Le CrUX (Chrome User Experience Report) publie le TTFB au 75e centile pour chaque origine et chaque URL suffisamment visitée. Deux précisions de la documentation Chrome : le TTFB n'y est collecté que sur les chargements complets de page (pas sur les navigations restaurées depuis le cache arrière-avant ni sur les pages préchargées), et il mélange visites à froid, visites servies par le cache ou un CDN et navigations internes sur une connexion déjà ouverte. Il n'est donc pas une mesure directe du temps de réponse du serveur.
- PageSpeed Insights affiche le TTFB de terrain issu du CrUX dans sa section sur l'expérience des utilisateurs réels, et signale côté laboratoire les problèmes de latence de la requête du document.
- Lighthouse mesure le temps de réponse du serveur, mais son audit exclut la résolution DNS et les redirections : il ne représente qu'une partie du TTFB.
- Les outils du navigateur : le panneau Réseau de Chrome DevTools détaille chaque phase de la requête (attente, DNS, connexion, TLS), et WebPageTest fait de même depuis des lieux et des connexions choisis.
- En JavaScript, l'API Navigation Timing expose
responseStart, et la bibliothèque web-vitals de Google fournit une fonctiononTTFBpour l'envoyer à un outil de mesure maison. - L'en-tête
Server-Timing, ajouté par le serveur à ses réponses, permet de détailler le temps passé dans la base de données, le rendu ou le cache, et de le lire dans DevTools comme dans les données de terrain. C'est le moyen de savoir, quand le TTFB est élevé, quelle partie du serveur est en cause.
Quand le TTFB de laboratoire dépasse nettement celui du terrain, l'environnement de test est simplement plus contraint que les visiteurs réels. Quand c'est l'inverse, le laboratoire manque quelque chose : un cache serveur qui ne sert que les tests, des redirections sur les URL d'entrée réelles, ou des visiteurs éloignés du serveur. Tester des pages peu visitées, ou ajouter un paramètre d'URL qui contourne le cache, permet de retrouver la valeur que subissent les visiteurs.
Comment réduire le TTFB
Le guide d'optimisation de web.dev, mis à jour en novembre 2025, ordonne les leviers du plus structurel au plus fin.
- L'hébergement vient en premier : mémoire allouée, versions à jour du langage et de la base de données, capacité à absorber le trafic réel. Un hébergement mutualisé convient à un petit site statique, pas à une application avec personnalisation et requêtes lourdes.
- Un CDN rapproche le contenu des visiteurs, résout le DNS rapidement, sert en HTTP/2 ou HTTP/3, négocie TLS 1.3 et compresse les réponses. C'est le levier le plus rentable pour un site dont l'audience est éloignée du serveur d'origine.
- Le cache, à tous les étages : cache de bord du CDN piloté par les en-têtes
Cache-Control, cache de page côté serveur, cache des requêtes coûteuses. Même une durée de cache courte change tout sur un site très visité, puisque seul le premier visiteur de la période paie le trajet jusqu'à l'origine. Attention aux paramètres d'URL de suivi, qui font passer une même page pour des pages différentes et contournent le cache. - Les redirections : chaque saut ajoute un aller-retour. Les redirections internes (absence de
https://, barre oblique finale manquante, www ou non) se corrigent dans les liens du site ; le passage de HTTP à HTTPS se supprime aux visites suivantes grâce à HSTS, et dès la première visite avec la liste de préchargement HSTS. - L'envoi progressif du HTML : les navigateurs traitent le balisage au fil de l'eau ; un serveur qui envoie les premiers octets avant d'avoir fini de générer la page, ou qui sert des pages générées à l'avance, réduit mécaniquement le TTFB.
- Un service worker avec une stratégie de type stale-while-revalidate peut rendre le TTFB quasi nul pour les pages qui changent peu, en les servant depuis le cache du navigateur puis en les rafraîchissant en arrière-plan.
- Les
103 Early Hintslaissent le navigateur commencer à charger les CSS et scripts critiques pendant que le serveur prépare la page. Ils n'aident guère un site statique et, comme le cache, ils peuvent masquer un serveur lent : d'où l'intérêt de mesurer aussi le temps serveur réel.
Les erreurs fréquentes
- Confondre TTFB et temps serveur. Un TTFB élevé peut venir du réseau, du DNS ou des redirections, pas du serveur ; à l'inverse, un audit Lighthouse qui ne mesure que le temps de réponse peut rester vert alors que les visiteurs subissent un long TTFB.
- Tester une page en cache et conclure que tout va bien. Le cache masque la lenteur du serveur ; il faut aussi mesurer les pages peu visitées et les requêtes qui contournent le cache.
- Optimiser le TTFB d'une application monopage sans traiter le rendu. Un HTML vide livré en 100 millisecondes ne sert à rien si le contenu met trois secondes à apparaître. Le TTFB se lit avec le FCP et le LCP.
- Empiler les redirections sur les URL d'entrée les plus exposées : liens de publicités, de newsletters, de réseaux sociaux, qui passent souvent par un raccourcisseur avant d'arriver sur le site.
- Chercher la milliseconde avant les secondes. Sous 0,8 seconde au 75e centile, le TTFB n'est plus le sujet ; le temps investi rapporte davantage sur les autres sous-parties du LCP.
Sources :
- Time to First Byte (TTFB) (web.dev (Google)), le 18 novembre 2025
- Optimize Time to First Byte (web.dev (Google)), le 28 novembre 2025
- Optimize Largest Contentful Paint (web.dev (Google)), le 31 mars 2025
- CrUX metrics (Chrome for Developers), le 18 novembre 2025
- Upcoming deprecation of Crawl Rate Limiter Tool in Search Console (Google Search Central Blog), le 24 novembre 2023
FAQ
Le TTFB est-il un critère de classement Google ?
Pas directement. Le TTFB ne fait pas partie des Core Web Vitals. Mais il est la première sous-partie du LCP, qui en fait partie, et représente environ 40 % du LCP sur une page bien optimisée. Un TTFB élevé rend un bon LCP difficile, et un serveur lent est aussi exploré moins vite par Googlebot.
Quel TTFB viser ?
0,8 seconde au plus au 75e centile des visites, selon web.dev ; au-delà de 1,8 seconde, le TTFB est considéré comme mauvais. Google présente ce seuil comme un repère à pondérer selon l'architecture : une application qui rend tout côté client a besoin d'un TTFB plus bas qu'un site rendu côté serveur.
Pourquoi mon TTFB est-il bon dans Lighthouse et mauvais dans PageSpeed Insights ?
Lighthouse mesure en laboratoire le temps de réponse du serveur, sans le DNS ni les redirections, depuis un point unique et souvent sur une page servie par le cache. PageSpeed Insights affiche aussi le TTFB de terrain issu du CrUX, qui inclut les redirections, les visiteurs éloignés, les réseaux lents et les pages non cachées. La valeur de terrain est celle que vivent les visiteurs.
Un CDN suffit-il à corriger un TTFB élevé ?
Souvent en grande partie, pour les pages qu'il peut mettre en cache : le contenu est servi près du visiteur, avec un DNS rapide, HTTP/3 et TLS 1.3. Mais les pages personnalisées ou non cachées repartent chercher l'origine, et un serveur lent reste lent. Le CDN ne dispense pas de regarder l'hébergement et le temps serveur.
Comment savoir quelle partie du TTFB pose problème ?
Le panneau Réseau de Chrome DevTools détaille les phases (redirection, DNS, connexion, TLS, attente). Pour le temps passé dans le serveur lui-même, l'en-tête Server-Timing permet de chronométrer la base de données, le rendu ou le cache et de lire ces valeurs dans DevTools comme dans les données de terrain.
En résumé
- TTFB : temps entre le début de la navigation et le premier octet reçu ; somme des redirections, du DNS, de la connexion TCP et TLS et du traitement serveur.
- Seuils : bon jusqu'à 0,8 s, mauvais au-delà de 1,8 s, au 75e centile ; repère approximatif, pas un Core Web Vital.
- Lien avec le LCP : première des quatre sous-parties du LCP, environ 40 % sur une page optimisée ; un TTFB élevé rend les 2,5 s du LCP difficiles à tenir.
- Mesure : CrUX et PageSpeed Insights pour le terrain ; DevTools, WebPageTest et Lighthouse en laboratoire (Lighthouse exclut DNS et redirections) ; Server-Timing pour le détail côté serveur.
- Leviers : hébergement, CDN, cache, suppression des redirections et HSTS, HTML envoyé progressivement, service worker, 103 Early Hints.
- Exploration : Googlebot ralentit automatiquement quand le temps de réponse augmente ; un serveur lent est aussi un serveur moins exploré.
Abondance c'est aussi des audits SEO, un service de contenus et des formations en e-learning !
Publié le Mis à jour le
Autres définitions :
Les outils SEO pour vous aider
