- →Le TTFB agrège DNS, connexion, TLS, redirections et traitement applicatif : un chiffre à 900 ms peut recouvrir un serveur qui répond en 70 ms derrière deux sauts de redirection.
- →Les bandes du Web Almanac 2025 (bon sous 0,8 s, mauvais au-delà de 1,8 s au 75e percentile) sont des repères de diagnostic, pas des seuils de classement : Google n'a jamais publié de couperet TTFB.
- →Le seuil qui compte est relatif au budget LCP de 2,5 s : à 1,2 s de TTFB, il ne reste que 1,3 s pour découvrir, télécharger et peindre l'élément principal.
- →Le parc n'avance quasiment pas : 55 % des sites desktop et 44 % des sites mobiles en bon TTFB dans les données HTTP Archive et CrUX de juillet 2025, soit un et deux points de mieux qu'en 2024 (Web Almanac 2025).
- →Le changement de responseStart dans Chrome en février 2025 casse la comparabilité historique : avec des Early Hints 103, le premier octet arrive avant que le HTML soit prêt, donc un TTFB très bas ne prouve plus rien.
- →Le TTFB d'un média qui vous fait un lien ne modifie pas la valeur de ce lien : il joue sur la fréquence d'exploration et sur les lecteurs qu'il conserve, pas sur le PageRank transmis.
Ce que mesure vraiment le premier octet
Le Time To First Byte compte le temps écoulé entre le début de la navigation et l'arrivée du premier octet de la réponse HTTP dans le navigateur. Ce n'est pas le temps de traitement de votre serveur, et confondre les deux fait perdre plus d'heures en diagnostic que n'importe quelle autre approximation de la mesure web. Le chiffre agrège la résolution DNS, l'ouverture de la connexion TCP, la poignée de main TLS, l'envoi de la requête, le travail applicatif, et seulement ensuite le premier octet renvoyé. Un TTFB à 900 millisecondes peut parfaitement recouvrir un serveur qui répond en 70 ms, derrière deux redirections et une connexion montée depuis l'autre hémisphère.
La documentation CrUX de Chrome le dit sans détour : la valeur remontée inclut la mise en place de la connexion et les redirections, et elle peut refléter une réponse servie depuis le cache du navigateur, depuis un CDN ou sur une connexion déjà ouverte. Deux mesures du même site, l'une depuis Paris en fibre avec cache chaud, l'autre depuis un mobile en 4G sur une première visite, ne décrivent pas le même phénomène. Toute comparaison de TTFB qui ne précise pas la localisation, l'état du cache et le type de navigation est une comparaison sans contenu.
Depuis février 2025, CrUX expose en plus les sous-parties du LCP mesurées sur le terrain : temps de réponse serveur, délai de chargement de la ressource, délai de rendu (bilan 2025 de DebugBear). Ces données sont accessibles via CrUX Visualisation et certains outils tiers, pas dans l'interface standard de PageSpeed Insights. C'est cette décomposition qui rend le TTFB exploitable. Seul, il vous apprend qu'une page démarre lentement, il ne vous dit jamais où.
Les seuils qui tiennent, et l'état réel du web
Les bandes de référence retenues par le Web Almanac 2025 sont sobres : bon en dessous de 0,8 seconde, à améliorer entre 0,8 et 1,8 seconde, mauvais au-delà de 1,8 seconde, mesuré au 75e percentile. Ce sont des repères de diagnostic. Google n'a publié aucun couperet de classement sur cette métrique, ni à 600 ni à 800 millisecondes, et un prestataire qui présente une de ces valeurs comme une limite algorithmique récente invente une règle qui n'existe pas dans la documentation Search Central.
L'état du parc mérite d'être connu avant de promettre quoi que ce soit à un client. L'analyse du Web Almanac 2025, construite sur les données HTTP Archive et CrUX de juillet 2025, donne 55 % des sites en bon TTFB sur desktop et 44 % sur mobile, contre 54 % et 42 % l'année précédente. Un point gagné sur ordinateur, deux sur mobile en douze mois : le web ne s'accélère quasiment pas de ce côté, alors que le taux de réussite global des trois signaux d'expérience de page atteint 56 % sur desktop et 48 % sur mobile dans le même rapport. Le TTFB est une composante, pas le goulot unique.
Le seuil qui compte vraiment en opération est relatif, pas absolu. Le budget publié par Google pour le rendu du plus grand élément visible est de 2,5 secondes. Si votre TTFB tourne à 1,2 seconde, il reste 1,3 seconde pour découvrir la ressource principale, la télécharger et la peindre, ce qui est intenable sur une connexion mobile en dehors d'une page très légère. C'est cette arithmétique qui doit fixer votre objectif : sur un site statique servi depuis un cache CDN, 200 ms sont atteignables et doivent être exigés. Sur une application dynamique avec appels en base à chaque requête, viser 800 ms est déjà un chantier sérieux.
Mesurer le TTFB sans se mentir
Les outils ne mesurent pas la même chose et coûtent très différemment, ce que la plupart des articles sur le sujet passent sous silence. L'onglet réseau de Chrome DevTools affiche la ligne d'attente de la réponse serveur : gratuit, immédiat, parfait pour isoler une ressource, sans aucune valeur pour conclure, parce que vous mesurez votre connexion, votre géographie et souvent un cache déjà chaud.
La mesure la plus honnête en ligne de commande reste cURL, qui décompose gratuitement et de façon reproductible. Un appel du type curl -s -o /dev/null -w "%{time_namelookup} %{time_connect} %{time_appconnect} %{time_starttransfer}" https://exemple.fr/ vous rend le DNS, la connexion TCP, la fin du TLS et le premier octet. L'écart entre time_appconnect et time_starttransfer est votre vrai temps applicatif ; tout ce qui précède relève du réseau et de la configuration TLS. Lancez la même commande depuis le serveur lui-même, sur 127.0.0.1, et vous obtenez la part strictement applicative, débarrassée du réseau. La différence entre les deux mesures est le diagnostic, pas la valeur brute.
WebPageTest, GTmetrix et Pingdom apportent le choix de la localisation et une méthodologie stable, à condition de toujours lire la première visite et non la mesure répétée : sur une page mise en cache par un CDN, le deuxième test ment par construction. CrUX, le bloc de données terrain de PageSpeed Insights et la Search Console donnent l'inverse, du réel agrégé au 75e percentile, mais avec une réserve documentée par Chrome : le TTFB n'est collecté que sur les chargements complets, alors que le LCP peut aussi l'être sur des navigations issues du cache arrière-avant ou de pages préchargées. Les tailles d'échantillon ne sont donc pas comparables entre métriques, et un TTFB terrain calculé sur peu de visites est un chiffre fragile.
Côté payant, DebugBear a ajouté en 2025 un test TTFB mondial qui compare les temps de réponse par localisation et indique si la réponse est sortie d'un cache CDN, ce qui est exactement ce qui manque quand on travaille à l'international. Le tarif relevé en juin 2026 démarre à 125 $ par mois pour l'offre Startup en monitoring synthétique, 325 $ avec du RUM, 899 $ pour l'offre entreprise, avec un essai mais pas d'offre gratuite permanente. Payer se justifie quand vous suivez plusieurs marchés et plusieurs origines. Pour arbitrer sur un site unique, CrUX et cURL suffisent.
Un piège de mesure spécifique à cette période mérite d'être connu : Chrome a modifié en février 2025 le comportement de responseStart pour s'aligner sur Firefox et Safari, qui comptaient déjà les données de réponse anticipée. Conséquence rapportée par DebugBear, un site qui émet des Early Hints en HTTP 103 voit son TTFB s'améliorer dans les rapports sans que la génération du HTML ait accéléré d'une milliseconde. Vos séries historiques ne sont pas comparables de part et d'autre de ce changement, et un TTFB très bas ne signifie plus que la page est prête.
TTFB, SEO et netlinking : ce qui est vrai
La documentation Google sur les Core Web Vitals liste trois métriques et trois seuils : LCP sous 2,5 secondes, INP sous 200 millisecondes, CLS sous 0,1. Le TTFB n'y figure pas, et la méthodologie CrUX le classe explicitement parmi les métriques expérimentales de diagnostic. Aucune des mises à jour confirmées de la période, core update de mars 2025 du 13 au 27 mars, core update de juin du 30 juin au 17 juillet, spam update d'août, core update de décembre 2025 du 11 au 29 décembre (Search Engine Land), n'a été présentée par Google comme touchant à la vitesse serveur : la mise à jour de décembre a été décrite comme une mise à jour ordinaire visant à faire remonter du contenu pertinent et satisfaisant. Rapporter un TTFB à un client comme un facteur de classement est une erreur factuelle.
Ce qui est vrai relève de deux mécaniques indirectes. La première est le budget de rendu déjà décrit : chaque milliseconde consommée avant le premier octet est une milliseconde retirée au LCP, qui lui compte. La seconde est l'exploration. Un serveur qui répond mal ou lentement voit Googlebot réduire sa cadence, ce qui allonge le délai entre la publication et la prise en compte, sujet traité en détail dans notre entrée sur le budget d'exploration. Sur un gros site, c'est là que le TTFB coûte réellement de l'argent.
En netlinking, la question qui revient est de savoir si le TTFB d'un domaine référent affecte la valeur du lien qu'il vous transmet. Rien dans la documentation Google ni dans les comptes rendus de mises à jour 2025 et 2026 ne soutient cette idée, et il faut le dire clairement plutôt que de laisser croire à un critère de plus. La pertinence thématique, l'autorité, l'indexabilité de la page porteuse et la qualité de la page cible restent les variables. Le TTFB d'un support intervient ailleurs : un média lent est exploré moins souvent, donc votre article met plus de temps à être découvert, et il perd des lecteurs avant même l'affichage, donc le trafic de renvoi fond. Quand vous filtrez le catalogue de supports consultable sans inscription, ce critère se regarde comme un indice d'exploitation sérieuse, pas comme un filtre bloquant. Sur les médias que nous opérons en propre, la question est réglée en amont par des builds statiques servis en cache : ce n'est pas un argument de vente, c'est simplement la conséquence d'un choix d'infrastructure fait une fois pour tout le parc.
Diagnostiquer, puis réparer dans l'ordre
L'erreur la plus fréquente que l'on croise en audit consiste à changer d'hébergement avant d'avoir isolé la cause. Dans une majorité des cas rencontrés, le coupable est une requête SQL non indexée, une extension qui appelle une API externe à chaque chargement de page, ou un cache de page désactivé sur une partie du site. Un serveur plus cher exécute le même mauvais code un peu plus vite, puis le problème revient dès que le trafic remonte.
La séquence qui fonctionne commence par la mesure interne. Comparez le TTFB depuis le serveur et depuis l'extérieur : si l'écart est faible et le total élevé, le problème est applicatif ; s'il est important, regardez la chaîne de redirections et la configuration TLS avant tout le reste, parce que chaque saut de redirection ajoute un aller-retour complet, DNS et poignée de main compris. Un site qui répond en apex puis redirige vers www puis vers HTTPS paie trois fois avant d'avoir servi un octet.
Vient ensuite le cache, dans ses trois étages : cache de page complet, cache objet, cache d'opcode côté PHP. Un TTFB qui oscille entre 120 millisecondes et 1,4 seconde selon les URL testées ne décrit pas un serveur lent, il décrit un cache partiellement froid ou des règles d'exclusion trop larges, souvent héritées d'un formulaire ou d'un panier. Le CDN se pose après, et seulement pour ce qui est cachable : placé devant du HTML non cachable, il ajoute un saut réseau sans rien accélérer.
Reste la saturation, qui se reconnaît à sa signature temporelle. Un TTFB stable en heure creuse et qui grimpe aux pics de trafic n'est pas un problème de latence mais une file d'attente : workers PHP-FPM insuffisants, pool de connexions à la base trop court, verrou applicatif. Aucune optimisation de configuration serveur ne réglera cela, il faut dimensionner ou déporter le travail. Enfin, les Early Hints sont un vrai levier pour laisser le navigateur précharger pendant que le HTML se fabrique, mais ne les activez pas pour améliorer un rapport : ils déplacent le repère de mesure sans accélérer la génération, et un chiffre embelli qui ne correspond à aucune amélioration perçue vous reviendra dessus au prochain audit.
Nautilinks opère un réseau de médias éditoriaux. Articles écrits en interne, mentions de transparence respectées, mix d'ancres calibré.
Questions fréquentes
Comment séparer, dans mon TTFB, ce qui vient du réseau et ce qui vient de l'application ?
Avec cURL et deux points de mesure. Depuis l'extérieur, relevez time_namelookup, time_connect, time_appconnect et time_starttransfer : la différence entre la fin du TLS et le premier octet est le temps applicatif, tout ce qui précède est réseau. Relancez la même commande sur 127.0.0.1 depuis le serveur : vous obtenez la part strictement applicative, sans réseau ni TLS. L'écart entre les deux relevés donne le coût de la distance, du DNS et des redirections. C'est ce delta qui oriente la correction, jamais la valeur brute.
Un TTFB sous 200 millisecondes garantit-il un bon LCP ?
Non, il enlève seulement une excuse. Le premier octet peut arriver très vite et l'élément principal peindre à 3 secondes parce qu'une feuille de style bloque le rendu, parce que l'image d'ouverture est déclarée en arrière-plan CSS et découverte tardivement, ou parce qu'une police en font-display block retient le bloc de texte candidat. Depuis février 2025, les sous-parties du LCP exposées dans CrUX permettent justement de voir si le temps est parti en réponse serveur, en découverte de ressource ou en rendu.
Pourquoi la Search Console et mon test GTmetrix ne donnent pas le même TTFB ?
Parce qu'ils ne mesurent pas la même population. La Search Console et le bloc terrain de PageSpeed Insights lisent CrUX, donc des visites Chrome réelles agrégées au 75e percentile, redirections et mise en place de connexion comprises, avec des états de cache variés. GTmetrix produit une mesure synthétique, depuis une localisation choisie, souvent sur une page déjà chaude en cache CDN. Le test synthétique sert à identifier la cause, le terrain sert à décider si le problème existe pour vos visiteurs.
Le TTFB d'un site sur lequel j'achète un lien change-t-il la valeur de ce lien ?
Rien dans la documentation Google ni dans les comptes rendus des mises à jour 2025 et 2026 ne soutient cette idée, donc non, pas directement. L'effet est ailleurs et bien réel : un support lent est exploré moins fréquemment, votre article met plus de temps à être découvert et indexé, et il perd des lecteurs avant affichage, donc le trafic de renvoi s'effondre. En audit d'achat, on regarde ce critère comme un indice de sérieux d'exploitation, au même titre que la régularité de publication.
Les Early Hints améliorent-ils le TTFB ou juste le chiffre affiché ?
Les deux, et il faut savoir lequel vous intéresse. Chrome a aligné en février 2025 son comportement de responseStart sur Firefox et Safari, qui comptaient déjà les données de réponse anticipée : un site émettant du HTTP 103 voit donc son TTFB rapporté baisser sans que le HTML soit généré plus vite. Le gain réel existe quand même, parce que le navigateur commence à précharger les ressources critiques pendant la fabrication de la page, ce qui profite au LCP. Ne présentez simplement pas la baisse du chiffre comme une accélération serveur.
Faut-il payer un outil de RUM pour piloter le TTFB ?
Pas pour un site unique sur un seul marché : CrUX pour le terrain et cURL pour le diagnostic couvrent l'essentiel sans dépenser un euro. L'abonnement se justifie quand vous suivez plusieurs pays et plusieurs origines, parce qu'un test lancé depuis une seule localisation masque la latence réellement subie sur vos marchés cibles. Chez DebugBear, qui a ajouté un test TTFB mondial en 2025, les tarifs relevés en juin 2026 commencent à 125 $ par mois en synthétique et 325 $ avec du RUM, sans offre gratuite permanente.
Testez vos connaissances
Quiz : Time To First Byte (TTFB)
1/3Selon la documentation Google et Chrome, quel est le statut du TTFB en 2026 ?