TTFB (Time to First Byte) : comment mesurer et améliorer votre temps de réponse serveur

Qu'est-ce que le TTFB ?

Le TTFB, ou Time to First Byte, mesure le temps qui s'écoule entre le moment où un navigateur commence à charger une page et le moment où le premier octet de la réponse commence à arriver. C'est une durée, exprimée en millisecondes (ms).

La définition de référence vient de la documentation officielle de Google sur web.dev :

Le TTFB est une métrique qui mesure le temps écoulé entre le début de la navigation vers une page et le début de l'arrivée du premier octet d'une réponse.

« TTFB is a metric that measures the time between starting navigating to a page and when the first byte of a response begins to arrive. »

Barry Pollard & Jeremy Wagner, web.dev (Google), article TTFB, mis à jour novembre 2025 (source)

Cette précision compte plus qu'il n'y paraît. Le TTFB ne mesure pas le temps de chargement total de la page, ni le moment où le contenu devient visible. Il mesure une seule chose : le temps que met l'infrastructure à répondre « voilà, je commence à t'envoyer quelque chose ». Tout ce qui suit, HTML, rendu, scripts, relève d'autres métriques. C'est là que la confusion s'installe : beaucoup rangent mentalement le TTFB dans la même case que le temps de chargement, alors que c'est l'inverse d'une fin de course, c'est le coup de pistolet du départ.

Ce délai vient d'étapes invisibles entre la requête et la réponse : résolution du nom de domaine, connexion sécurisée, et surtout le travail que le serveur fournit pour fabriquer la page. Une page statique en cache peut répondre en 50 ms ; une page produit qui interroge une base de données, calcule un panier et applique une promotion peut mettre 1 200 ms à produire ce même premier octet. Même URL, même navigateur : tout se joue côté serveur.

Retenez la distinction qui fait toute la différence dans un audit : un TTFB élevé est un problème de back-end. Un temps de chargement élevé avec un bon TTFB est un problème de front-end. Confondre les deux, c'est optimiser le mauvais bout de la chaîne pendant des semaines.

Les 4 phases qui composent le TTFB

Le TTFB n'est pas une seule opération, c'est une somme. Pour comprendre où votre temps part, il faut décomposer ce qui se passe entre le clic et le premier octet. Voici les phases, dans l'ordre chronologique :

1. Le temps de redirection : Si l'URL demandée renvoie vers une autre adresse (http:// vers https://, ou une 301), chaque redirection ajoute un aller-retour complet. Une chaîne de deux ou trois redirections en cascade peut ajouter plusieurs centaines de millisecondes.
2. Le démarrage du service worker, le cas échéant (typiquement une PWA) : son temps de démarrage entre dans le calcul, mais la plupart des sites ne sont pas concernés.
3. Larésolution DN : Le navigateur traduit le nom de domaine en adresse IP, une étape qui peut être lente si le résolveur est éloigné ou le domaine peu visité (pas de cache DNS local).
4. L'établissement de la connexion et la négociation TLS : Le navigateur ouvre une connexion TCP (le « three-way handshake »), puis négocie le chiffrement TLS pour le HTTPS, plusieurs allers-retours pour échanger les clés. Plus le serveur est loin, plus chaque aller-retour coûte cher.
5. Le traitement de la requête par le serveur applicatif, jusqu'à l'envoi du premier octet : Sur un site dynamique non mis en cache, cette phase concentre l'essentiel du problème.

La structure logique à retenir : les phases 1 à 4 relèvent du réseau, la phase serveur relève de l'application. Face à un TTFB élevé, la question est : le temps part-il dans le réseau ou le serveur ? Cela se mesure, on y vient. Cette décomposition explique aussi la sensibilité géographique du TTFB : un utilisateur à Sydney qui charge un serveur à Roubaix paie la latence physique des phases DNS, connexion et TLS.

Quels sont les seuils de référence ?

Voici le point où la majorité des contenus francophones se trompent.

Les seuils officiels, mesurés au 75e centile des utilisateurs, sont les suivants :

Source : web.dev (Google), article TTFB. La page indique explicitement que « les bonnes valeurs de TTFB sont de 0,8 seconde ou moins, et les mauvaises valeurs sont supérieures à 1,8 seconde ».

Le mythe des 200-400 ms selon Google

Maintenant, l'idée reçue à démolir : si vous cherchez « seuils TTFB » en français, les premiers résultats affirment souvent qu'un bon TTFB se situe « entre 200 et 400 ms selon Google ». C'est faux, ce chiffre ne figure dans aucune documentation officielle actuelle de Google : il circule depuis des années, recopié d'article en article, un chiffre rond jamais sourcé qui a fini par acquérir l'autorité d'un fait par répétition. Le seuil officiel publié sur web.dev est de 800 ms, le double de la borne haute de cette légende. Conséquence concrète : piloter son infrastructure sur 400 ms alors que le seuil réel est 800 ms, c'est risquer d'investir dans un upgrade coûteux pour des millisecondes que Google ne récompense pas ; à l'inverse, un TTFB à 700 ms est déjà dans le vert.

Dernier point sur la méthode : ces seuils s'évaluent au 75e centile, c'est-à-dire que 75 % des utilisateurs réels doivent être sous le seuil pour que la page soit considérée comme bonne. Une moyenne peut masquer une longue traîne d'utilisateurs mal servis ; un TTFB médian flatteur ne dit rien du 75e centile, la valeur que Google regarde via les données de terrain.

Pourquoi le TTFB impacte le SEO ?

Disons-le clairement : le TTFB n'est pas un Core Web Vital. web.dev est sans ambiguïté : « Comme le TTFB n'est pas une métrique Core Web Vitals, il n'est pas absolument nécessaire que les sites atteignent le seuil de "bon" TTFB. » Alors pourquoi en parler ? Parce que ne pas être un Core Web Vital ne signifie pas être sans effet sur le classement : le TTFB agit en amont, par effet de cascade. C'est ce que dit la même source :

Le TTFB précède les métriques axées sur l'utilisateur telles que le FCP et le LCP.

« Because TTFB precedes user-centric metrics such as First Contentful Paint (FCP) and Largest Contentful Paint (LCP)... »

Barry Pollard & Jeremy Wagner, web.dev (Google), article TTFB, mis à jour novembre 2025 (source)

La chaîne causale TTFB, FCP, LCP

Le navigateur ne peut rien afficher tant qu'il n'a pas reçu de HTML. Le TTFB, c'est le moment où ce HTML commence à arriver : le First Contentful Paint ne peut donc pas se produire avant lui, et le Largest Contentful Paint vient encore après le FCP. La séquence est rigide : TTFB, puis FCP, puis LCP.

Faites le calcul : le seuil « bon » du LCP est de 2,5 secondes. Si le TTFB en consomme 1,5, il reste 1 seconde pour télécharger le HTML, découvrir l'élément LCP et le peindre à l'écran, jouable mais serré. À 2 secondes de TTFB, le seuil LCP est déjà dépassé avant tout affichage : aucune optimisation d'image ne rattrapera ce retard, le plafond est posé en amont.

Voilà notre position : la plupart des audits attaquent par le front parce que c'est plus visible en réunion. C'est une erreur de séquencement. Tant que le TTFB n'est pas sous contrôle, optimiser le front revient à repeindre une façade sur des fondations qui s'enfoncent, c'est lui qui décide du plafond des Core Web Vitals, et donc de la part « expérience de page » du SEO technique.

L'effet SEO du TTFB est donc indirect mais réel : il pèse parce qu'il conditionne le LCP, un Core Web Vital pris en compte dans l'expérience de page. Réduire son TTFB, c'est dégager du budget pour les métriques qui comptent vraiment pour Google.

Comment mesurer son TTFB ?

On ne pilote pas ce qu'on ne mesure pas. Trois outils suffisent, chacun avec un usage distinct.

• PageSpeed Insights donne le TTFB en données de terrain (CrUX), l'expérience réelle des utilisateurs Chrome sur 28 jours, la valeur la plus proche de ce que Google « voit ». Si le site manque de trafic, seules les données de laboratoire s'affichent, un TTFB simulé, celui que mesure aussi Google Lighthouse.
• Google Chrome DevTools est l'outil le plus précis pour une mesure ponctuelle : onglet « Network », rechargez la page, cliquez sur la première requête. Dans le panneau « Timing », « Waiting for server response » correspond au temps de traitement serveur, qui domine généralement le TTFB ; les phases DNS, « Initial Connection » (la connexion TCP) et SSL y sont détaillées séparément.
• WebPageTest est l'outil le plus complet : il affiche le TTFB en haut du rapport, le décompose dans son diagramme de chargement, et permet de tester depuis différentes localisations. En cas de doute sur la distance serveur-utilisateur, comparez un test proche et un test éloigné : l'écart indique ce que coûte la géographie.

Ces outils ne mesurent pas la même chose : PageSpeed Insights en données de terrain reflète les vrais utilisateurs, DevTools et WebPageTest une visite synthétique. Croisez les deux pour un diagnostic honnête. Le Speed Index suit la même logique lab/terrain et complète le diagnostic sur la vitesse perçue ; pour un suivi dans la durée, voir notre comparatif des outils de monitoring continu.

Pour une mesure automatisée en continu, l'API navigateur Navigation Timing expose le TTFB en JavaScript via responseStart, la valeur brute que ces outils recalculent en coulisses, exploitable dans un outil de RUM.

Les principales causes d'un TTFB élevé

Avant de poser des leviers, il faut établir un diagnostic. Voici les coupables, du plus fréquent au plus spécifique.

• L'hébergement mutualisé : Sur un serveur partagé, on cohabite avec des dizaines d'autres sites : si l'un d'eux subit un pic de trafic, le temps de réponse en pâtit sans qu'on ait rien fait. Cause numéro un des TTFB erratiques (300 ms à 4 h du matin, 1 400 ms à 14 h), et la plus sous-estimée, car elle n'apparaît pas dans un test ponctuel fait au calme.
• Le contenu dynamique servi sans cache : Cas typique d'un site WordPress ou PrestaShop qui régénère chaque page à chaque visite, même quand le contenu n'a pas changé depuis trois semaines. C'est du gaspillage de temps machine pur, et le levier le plus rentable à corriger.
• Les requêtes base de données et appels API lents : Une page qui déclenche quinze requêtes SQL non optimisées, ou attend une API externe (paiement, stock, widget tiers), accumule le délai de chaque appel dans son TTFB. Un seul appel API à 800 ms suffit à faire basculer la page dans l'orange.
• L'absence de réseau de distribution de contenu :  Sans CDN, tous les utilisateurs frappent le même serveur d'origine. Plus ils en sont loin, plus la latence réseau gonfle les phases DNS, connexion et TLS. Un site hébergé en France peut être correct pour les Parisiens et catastrophique pour les Québécois.

À ces causes structurelles s'ajoutent des suspects plus discrets : chaînes de redirection, certificat TLS mal configuré, PHP obsolète. Le bon réflexe : mesurer d'abord avec Google Chrome DevTools où part le temps. Si « Waiting for server response » domine, le problème est applicatif ; si ce sont les phases DNS, connexion et SSL qui s'étirent, il est réseau. Le diagnostic conditionne le levier.

Comment améliorer son TTFB côté serveur ?

On passe à l'action. Les leviers serveur attaquent la phase qui domine le TTFB : le traitement applicatif. Classés du plus rentable au plus engageant.

1. Activer un cache serveur (cache de page complet) : Le levier le plus sous-estimé : au lieu de régénérer la page à chaque visite, le serveur sert un HTML déjà prêt. Un TTFB de 1 200 ms peut tomber sous 200 ms sans toucher au code. Sur WordPress, un reverse proxy (Varnish) ou une extension de cache change la donne ; sur PrestaShop, le cache intégré + reverse proxy fait de même. Plus complexe sur les zones dynamiques (panier, prix personnalisés), où interviennent le cache fragmenté ou le hole punching.
2. Optimiser la base de données et les appels applicatifs : Si le cache complet n'est pas applicable : index, suppression des requêtes redondantes, cache objet (Redis, Memcached), parallélisation des appels API externes. Sur un gros catalogue, ce travail peut diviser le temps de traitement par deux ou trois.
3. Monter de gamme côté hébergement : Une fois cache et optimisation épuisés, le problème devient matériel : serveur dédié, VPS dimensionné ou cloud élastique. Le levier le plus coûteux, à réserver pour la fin, avec un bénéfice secondaire : moins de requêtes inutiles traitées, moins de consommation électrique (voir notre article sur l'impact du CMS sur la facture énergétique).
4. Maintenir une stack serveur à jour : Passer à une version récente de PHP réduit le temps de traitement ; activer HTTP/2 multiplexe les requêtes et réduit la latence réseau. Faible risque, effet immédiat, mais ça accompagne un cache, ça ne le remplace pas.

L'erreur classique : changer d'hébergeur (levier 3) avant d'avoir activé le cache, on paie trois fois plus cher pour refaire le même travail inutile. Cache d'abord, optimisation applicative ensuite, matériel en dernier recours.

CDN et optimisations réseau

Jusqu'ici, on a traité la phase serveur. Mais les phases DNS, connexion et TLS dépendent de la distance physique entre l'utilisateur et le serveur, une distance qu'aucun cache applicatif ne réduit. C'est le terrain du réseau de distribution de contenu.

Un CDN (Content Delivery Network) est un réseau de serveurs répartis géographiquement, qui stockent une copie du contenu au plus près des utilisateurs : au lieu qu'un visiteur de Tokyo frappe le serveur d'origine à Roubaix, sa requête est servie par le point de présence le plus proche. Le CDN améliore le TTFB de deux façons distinctes.

D'abord, il réduit la latence réseau pure : les phases DNS, connexion et TLS coûtent proportionnellement à la distance, et rapprocher le point de terminaison raccourcit chaque aller-retour, un gain purement géographique. Ensuite, et c'est le levier le plus puissant, un CDN peut mettre en cache les pages HTML à la périphérie (edge caching) : la requête n'atteint alors jamais le serveur d'origine, avec un TTFB qui se compte en dizaines de millisecondes, imbattable pour un contenu statique ou semi-statique.

La nuance qui sépare une mise en place réussie d'une déception : un CDN mal configuré peut dégrader le TTFB au lieu de l'améliorer, s'il ne met pas les pages HTML en cache, chaque requête ajoute un saut supplémentaire sans bénéfice. La règle : un CDN n'améliore le TTFB des pages que si le cache du HTML est explicitement configuré à la périphérie, avec une politique d'invalidation propre.

Deux optimisations réseau complémentaires : réduire les chaînes de redirection (chaque redirection ajoute un aller-retour complet) et choisir un fournisseur DNS performant, à la couverture géographique large, pour raccourcir la première phase du TTFB. Des gains modestes pris isolément, mais qui s'additionnent.

Techniques avancées : 103 Early Hints et optimisations modernes

Voici le terrain où le SERP francophone est totalement silencieux. La plupart des optimisations vues jusqu'ici cherchent à réduire le TTFB ; une approche plus récente accepte que le serveur ait besoin de temps, mais en profite pour faire travailler le navigateur pendant ce temps mort.

C'est le rôle du code HTTP 103 Early Hints. Pendant que le serveur assemble la réponse finale, au lieu de laisser le navigateur attendre bras croisés, il envoie une réponse préliminaire : « je travaille encore, mais voici déjà les ressources critiques à charger ». Le navigateur précharge alors le CSS, les polices ou l'image LCP pendant que le serveur finit son traitement.

L'effet est subtil : 103 Early Hints ne réduit pas le temps de traitement serveur, le TTFB de la réponse finale ne baisse donc pas mécaniquement. Ce qu'il optimise, c'est ce qui se passe pendant le TTFB, un temps utile de préchargement au lieu d'un temps mort. Résultat : le FCP et le LCP arrivent plus tôt. Ranger cette technique dans la case « optimisation TTFB » est donc techniquement imprécis : le TTFB ne bougera pas, le LCP, lui, s'améliorera.

À qui s'adresse cette technique ? Aux sites dont le traitement serveur reste structurellement élevé malgré la mise en cache et l'optimisation applicative. Sur un site déjà servi depuis un cache en quelques dizaines de millisecondes, elle n'apporte presque rien ; sur une page dynamique qui met 700 ms à se construire, ces 700 ms deviennent du temps de préchargement productif. Une technique de frontière, à réserver aux sites qui ont épuisé les leviers classiques.

La leçon dépasse 103 Early Hints : quand on ne peut plus réduire le TTFB, on peut encore changer ce qu'on fait pendant le TTFB, streaming du HTML, rendu progressif, hiérarchisation des ressources critiques. Le TTFB cesse d'être un mur et devient un budget à dépenser intelligemment.

Conclusion

Le TTFB n'est pas une métrique de tableau de bord parmi d'autres : c'est le plafond de verre de votre performance. Tant qu'il dépasse les 800 ms du seuil officiel web.dev, vos optimisations front se battent contre un budget déjà entamé, et votre LCP restera difficile à passer dans le vert. La bonne séquence d'un audit commence par le serveur, pas par les images : mesurez d'abord où part le temps via Google Chrome DevTools, activez la mise en cache avant tout investissement matériel, puis attaquez le réseau avec un CDN qui met réellement le HTML en cache. Le TTFB n'est que la première étape d'une chaîne plus longue : une fois le HTML reçu, la réactivité de la page dépend aussi du Total Blocking Time puis du Time to Interactive, qui prennent le relais jusqu'à ce que l'utilisateur puisse pleinement interagir.

Si votre LCP résiste à toutes vos optimisations front et que vous soupçonnez le serveur, un audit technique de performance isole la cause exacte de votre TTFB et priorise les leviers par impact réel sur vos Core Web Vitals. Lead Reactor réalise ce diagnostic et construit le plan d'action correspondant. Parlons de votre cas.