Avant qu’un seul pixel ne s’affiche, avant que la moindre image ne se télécharge, avant même que le navigateur ne sache à quoi ressemblera la page, il attend une chose : le premier octet de la réponse du serveur. Le temps qui s’écoule jusqu’à cet instant porte un nom, le TTFB (Time To First Byte), et il conditionne tout ce qui suit. Une page ne peut pas être rapide si son premier octet est lent : chaque milliseconde de TTFB se répercute intégralement sur toutes les métriques suivantes, du premier rendu au LCP.
Le TTFB est pourtant le grand oublié des optimisations. Il ne fait pas partie des Core Web Vitals, il ne se voit pas dans une capture d’écran, et il se joue dans des couches (réseau, serveur, base de données) moins visibles que le front-end. C’est aussi une métrique plus subtile qu’il n’y paraît : selon l’outil qui la mesure et la définition qu’il retient, deux chiffres de TTFB peuvent ne pas parler de la même chose, et les comparer sans précaution mène à de mauvaises décisions.
Après nos guides consacrés au LCP, au CLS et à l’INP, ce nouvel article de notre série sur les métriques décortique le Time To First Byte : ce qu’il mesure exactement, comment l’évaluer sans se tromper, ce qui le dégrade côté réseau et côté serveur, et les leviers pour le ramener sous les seuils recommandés.
Qu’est-ce que le TTFB ?
Le TTFB, ou Time To First Byte, est le temps écoulé entre le début de la navigation et l’arrivée du premier octet de la réponse HTML. Un bon TTFB est inférieur ou égal à 800 millisecondes au 75e percentile des visites, mauvais au-delà de 1,8 seconde.
La définition de référence, donnée par web.dev, est la suivante : le TTFB est le temps écoulé entre le début de la navigation et l’arrivée du premier octet de la réponse HTML. Ce délai n’est pas un bloc monolithique : il agrège toute une succession d’étapes, chacune pouvant devenir le maillon faible. Les redirections éventuelles, la résolution DNS, l’établissement de la connexion TCP, la négociation TLS, l’envoi de la requête, puis le temps de traitement du serveur et le trajet retour de la réponse : le TTFB est la somme de tout ce qui précède le premier octet, et l’optimiser commence par identifier laquelle de ces étapes pèse le plus.
Côté seuils, web.dev recommande de viser un TTFB inférieur ou égal à 800 ms au 75e percentile des visites, et considère comme mauvaise toute valeur au-delà de 1,8 seconde. La logique derrière ces chiffres est arithmétique : le seuil de bon LCP est fixé à 2,5 secondes par la documentation officielle, et le TTFB en consomme la première tranche. Un TTFB de 1,8 seconde ne laisse que 700 ms pour télécharger et afficher l’élément principal de la page : autant dire que la partie est perdue d’avance. C’est précisément ce que montre la décomposition du LCP en sous-parties proposée par web.dev, dont le TTFB est le premier des quatre segments.
Une métrique, plusieurs définitions
Un avertissement s’impose avant de comparer des chiffres. Comme le détaille Robin Marx, architecte web performance chez Akamai, dans son article du Web Performance Calendar 2025, le terme TTFB recouvre plusieurs définitions concurrentes selon les outils : certains mesurent depuis le début de la navigation, redirections comprises, d’autres depuis l’envoi de la requête sur une connexion déjà établie, d’autres encore excluent le DNS ou le TLS. Un TTFB relevé par curl sur une connexion neuve, celui affiché par les DevTools et celui remonté par les données terrain de Chrome ne mesurent pas exactement le même intervalle.
Des mécanismes récents comme le préchargement spéculatif, que nous avons exploré dans notre article sur les Speculation Rules et le prerendering, brouillent encore la lecture : une page prérendue affiche un TTFB quasi nul qui ne dit plus rien du serveur. La règle pratique est simple : toujours comparer des mesures issues du même outil, dans les mêmes conditions, et documenter ce que l’on mesure.
Qu’est-ce qu’un bon TTFB ?
Un bon TTFB est inférieur ou égal à 800 millisecondes, à améliorer entre 800 ms et 1,8 seconde, et mauvais au-delà. Ces seuils s’apprécient au 75e percentile des visites, c’est-à-dire pour trois visiteurs sur quatre, appareils modestes et connexions lentes compris.
| Valeur au 75e percentile | Verdict | Conséquence sur le LCP |
|---|---|---|
| ≤ 800 ms | Bon | Budget confortable pour les 3 autres sous-parties |
| 800 ms à 1,8 s | À améliorer | Budget contraint, LCP difficile à tenir |
| > 1,8 s | Mauvais | Bon LCP hors d’atteinte |
La troisième colonne explique pourquoi ces seuils comptent. Le seuil de bon LCP étant fixé à 2,5 secondes, un TTFB de 1,8 seconde ne laisse que 700 ms pour découvrir, télécharger et afficher l’élément principal. La partie est alors perdue avant d’avoir commencé, quel que soit le soin apporté au front-end.
Un repère utile pour situer votre site : l’audit Lighthouse intitulé réduire le temps de réponse initial du serveur se déclenche précisément sur ce critère. S’il apparaît dans votre rapport, votre TTFB dépasse le seuil, et c’est le premier point à traiter avant toute optimisation d’images ou de scripts.
Comment mesurer le TTFB ?
Mesurez le TTFB à deux endroits : dans l’onglet Réseau des outils de développement ou en JavaScript avec l’API PerformanceNavigationTiming pour diagnostiquer, et dans les données de terrain de Chrome pour connaître la valeur réellement vécue. Le laboratoire explique, le terrain arbitre, et les deux ne donnent jamais le même chiffre.
La mesure la plus directe se fait dans l’onglet Réseau des DevTools : la première ligne de la cascade, celle du document HTML, détaille dans son onglet Timing le temps d’attente de la réponse serveur, décomposé en phases (DNS, connexion, TLS, attente). En JavaScript, l’API PerformanceNavigationTiming expose les mêmes horodatages, et le TTFB correspond à l’attribut responseStart, mesuré depuis le début de la navigation. C’est cette définition, redirections et connexion comprises, que retiennent les outils de l’écosystème Chrome, et c’est elle que nous utilisons dans la suite de cet article :
const [nav] = performance.getEntriesByType('navigation');
console.log('TTFB :', nav.responseStart, 'ms');
// Décomposition des étapes qui le composent
console.log('Redirections :', nav.redirectEnd - nav.redirectStart, 'ms');
console.log('DNS :', nav.domainLookupEnd - nav.domainLookupStart, 'ms');
console.log('TCP + TLS :', nav.connectEnd - nav.connectStart, 'ms');
console.log('Requête + serveur :', nav.responseStart - nav.requestStart, 'ms');Ces mesures de laboratoire ont une limite : elles décrivent votre connexion, depuis votre machine, à un instant donné. Vos visiteurs, eux, se connectent depuis d’autres réseaux, d’autres continents, d’autres appareils. Les données de terrain du Chrome UX Report agrègent le TTFB réellement vécu par les utilisateurs de Chrome sur votre site, au 75e percentile, et constituent la seule base fiable pour juger de la situation réelle.
La distinction entre ces deux familles d’outils est un sujet en soi, que nous avons traité dans notre comparatif PageSpeed Insights contre Lighthouse : retenez qu’un TTFB de laboratoire sert à diagnostiquer, et qu’un TTFB de terrain sert à prioriser et à constater les progrès.
Le piège des moyennes et des distributions à deux bosses
Un dernier réflexe de mesure fait toute la différence : ne jamais raisonner en moyenne. Le TTFB d’un site caché forme typiquement une distribution à deux bosses : une population de requêtes servies depuis le cache, en quelques dizaines de millisecondes, et une population de requêtes générées à la demande, dix à cinquante fois plus lentes. La moyenne des deux tombe dans un entre-deux qui ne correspond à l’expérience de personne, et masque aussi bien un taux de hit médiocre qu’une génération anormalement lente.
C’est la raison pour laquelle les données de terrain s’expriment au 75e percentile : cette valeur garantit que trois visiteurs sur quatre vivent une expérience au moins aussi bonne que le chiffre affiché. En pratique, le bon réflexe consiste à examiner les deux populations séparément : le TTFB des pages cachées mesure la santé de l’infrastructure de diffusion, celui des pages non cachées mesure la santé de la génération. Les confondre, c’est optimiser à l’aveugle.
Qu’est-ce qui ralentit le TTFB côté réseau ?
Cinq postes consomment du temps avant même que votre serveur ne reçoive la requête : les redirections, la résolution DNS, la poignée de main TCP, la négociation TLS et la compression du HTML. Chaque étape ajoute une fois la latence du visiteur, ce qui se chiffre vite sur un réseau mobile.
Une part du TTFB se consomme avant même que votre serveur ne reçoive la requête. À ce stade, tout se compte en allers-retours : chaque étape ajoute une fois la latence du visiteur au temps d’attente, et cette latence se chiffre vite en dizaines de millisecondes sur un réseau mobile. Cinq chantiers composent ce chapitre : les redirections, l’établissement de la connexion, le protocole, la distance géographique et la compression, auxquels s’ajoute un dispositif à part, les Early Hints, qui ne réduit pas l’attente mais la rentabilise.
Les redirections, la latence payée en double
Le premier poste, souvent négligé, est la redirection : chaque saut (de HTTP vers HTTPS, de l’apex vers le www, d’une ancienne URL vers la nouvelle) coûte un aller-retour réseau complet, et les chaînes de redirections les additionnent. La documentation MDN rappelle qu’elles se cumulent silencieusement au fil des migrations : un lien externe en HTTP vers un ancien domaine peut traverser trois redirections avant d’atteindre la page finale, soit trois fois la latence du visiteur ajoutées au TTFB avant le moindre travail utile.
Le chantier des redirections se mène en deux temps. L’inventaire d’abord : les rapports d’exploration de la Search Console et un crawl du site révèlent les chaînes existantes, et la commande curl -IL permet de suivre pas à pas le parcours d’une URL donnée. La réduction ensuite : chaque redirection conservée doit mener directement à l’URL finale, en un seul saut, y compris depuis les variantes historiques du domaine. Les liens internes du site, eux, ne devraient jamais transiter par une redirection : pointer directement vers l’URL canonique est un gain gratuit, répété sur chaque navigation de chaque visiteur.
Un cas particulier peut être supprimé plutôt qu’optimisé : la redirection de HTTP vers HTTPS, présente sur la quasi-totalité des sites. L’en-tête HSTS, documenté par MDN, ordonne au navigateur de ne plus jamais tenter la version non chiffrée : dès la deuxième visite, ce saut disparaît purement et simplement du parcours. L’inscription sur la liste de préchargement HSTS embarquée dans les navigateurs étend la protection à la toute première visite : le saut de HTTP vers HTTPS n’est plus jamais payé.
DNS, TCP, TLS : le ticket d’entrée de chaque connexion
Avant le premier octet utile, une connexion neuve enchaîne trois étapes : la résolution DNS, qui traduit le nom de domaine en adresse IP, la poignée de main TCP, qui établit le canal, et la négociation TLS, qui le chiffre. Chacune coûte un ou plusieurs allers-retours, et leur poids total dépend directement de la latence entre le visiteur et le serveur. Sur une connexion fibre à 5 ms de latence, l’addition est indolore ; sur un mobile en zone moyenne, elle peut représenter à elle seule plusieurs centaines de millisecondes de TTFB.
Chaque étape a son levier, à commencer par le DNS, qu’on croit à tort uniforme : la résolution dépend du fournisseur qui héberge votre zone, et tous n’offrent pas le même niveau de performance. Les mesures continues de DNSPerf (source secondaire) montrent des écarts sensibles de temps de réponse entre fournisseurs en Europe, Cloudflare occupant régulièrement la tête du classement. Changer de fournisseur de zone est une opération indolore et souvent gratuite, et des TTL raisonnables évitent par ailleurs les résolutions répétées.
Côté TLS, la version du protocole compte : TLS 1.3, spécifié par la RFC 8446, réduit la négociation à un seul aller-retour là où TLS 1.2 en exigeait deux, et sa reprise de session raccourcit encore les connexions suivantes. Pour les domaines tiers critiques, l’indication rel="preconnect" permet enfin de payer ce ticket d’entrée en avance, pendant que le navigateur est encore occupé ailleurs.
HTTP/3 et QUIC : des poignées de main fusionnées
La refonte la plus radicale de ce ticket d’entrée vient du protocole lui-même. HTTP/3, standardisé par la RFC 9114, abandonne TCP au profit de QUIC, un transport bâti sur UDP et spécifié par la RFC 9000, qui fusionne l’établissement du canal et son chiffrement en une seule poignée de main. QUIC autorise même, lors d’une reconnexion à un serveur déjà connu, l’envoi de données dès le premier paquet, et maintient la connexion vivante quand l’appareil change de réseau, du Wi-Fi à la 4G, sans tout renégocier.
Bonne nouvelle : l’activation ne demande généralement aucun chantier. Les CDN et les serveurs web récents la proposent en un réglage, et le navigateur découvre la disponibilité du protocole via l’en-tête Alt-Svc avant de basculer aux visites suivantes. Le contrôle est tout aussi simple : la disponibilité se vérifie dans la colonne Protocole des DevTools, où les requêtes servies en HTTP/3 s’affichent en h3. Un site encore intégralement en h2, voire en http/1.1, laisse des allers-retours sur la table à chaque nouvelle connexion.
La découverte via Alt-Svc a toutefois une limite : elle ne profite qu’aux visites suivantes, la toute première connexion s’établissant encore sur la pile TCP et TLS classique. Les enregistrements DNS SVCB et HTTPS, standardisés par la RFC 9460, comblent ce manque : publiés dans la zone du domaine, ils annoncent les protocoles supportés dans la réponse DNS elle-même. Le navigateur sait ainsi, avant même d’ouvrir la connexion, qu’il peut parler QUIC : HTTP/3 est utilisé dès la toute première connexion, sans passage préalable par h2. La plupart des CDN publient ces enregistrements automatiquement pour les zones qu’ils gèrent ; sur une zone administrée à la main, un enregistrement de type HTTPS portant le paramètre alpn="h3" suffit.
La distance géographique : le levier CDN
Tous les allers-retours précédents ont un coût proportionnel à la distance : la latence physique étant incompressible, les raccourcir passe par le rapprochement. C’est le rôle géographique du CDN : placer un point de terminaison à proximité de chaque visiteur, si bien que DNS, poignées de main et chiffrement se négocient sur quelques dizaines de kilomètres plutôt que sur un continent. Pour un trafic international, rapprocher la terminaison de la connexion reste le levier réseau le plus efficace, loin devant tout réglage fin de protocole.
Le bénéfice dépasse largement les fichiers statiques : même une page dynamique non cacheable profite d’un CDN, car la connexion du visiteur se termine à l’edge, et l’edge dialogue ensuite avec votre serveur sur des connexions déjà établies, maintenues chaudes entre les requêtes. Le visiteur paie la latence courte, l’infrastructure paie la longue.
Cette latence longue, entre l’edge et l’origine, s’optimise elle aussi. Cloudflare Argo Smart Routing en est un bon exemple : plutôt que de suivre le routage par défaut d’Internet, le service fait transiter les requêtes vers votre serveur par les chemins les plus rapides et les moins congestionnés du réseau Cloudflare, mesurés en continu, comme le décrit sa documentation officielle. Le gain est maximal pour les visiteurs les plus éloignés de l’origine, précisément ceux dont le TTFB souffre le plus. Les autres apports de ces réseaux, cache partagé compris, sont détaillés dans notre analyse des avantages et inconvénients des CDN.
103 Early Hints : rentabiliser l’attente incompressible
Quand le serveur a réellement besoin de temps pour générer la page, une partie de l’attente peut être mise à profit plutôt que subie. Le code de statut 103 Early Hints, décrit dans la documentation Chrome, permet au serveur ou au CDN d’envoyer une réponse préliminaire pendant que la page se génère, indiquant au navigateur les ressources critiques (feuille de style, police, image principale) à précharger sans attendre le HTML.
Le TTFB mesuré ne change pas, mais le temps qu’il représente cesse d’être du temps mort : à l’arrivée du premier octet, une partie des ressources est déjà en cours de téléchargement. C’est un dispositif de second rideau, à considérer une fois les fondamentaux en place, mais il illustre une idée utile : le TTFB se réduit d’abord, et ce qui en reste peut encore se rentabiliser.
En pratique, le dispositif suppose un maillon capable d’émettre le 103 avant que l’origine n’ait répondu : c’est le plus souvent le CDN qui mémorise les indications et les sert dès la requête suivante, comme le décrit la documentation Cloudflare. Le gain croît mécaniquement avec le temps de génération : plus votre serveur réfléchit longtemps, plus la fenêtre à rentabiliser est large. Un site au TTFB déjà excellent n’en tirera presque rien ; un site dynamique lent à générer, beaucoup.
La compression du HTML, dans le chemin critique
Un dernier poste réseau se niche là où on ne l’attend pas : la compression. Sur une page dynamique, le HTML est compressé à la volée, à chaque requête, et ce temps de compression s’ajoute au TTFB. C’est ce qui justifie de choisir l’algorithme selon le type de contenu, un arbitrage que nous avons détaillé dans notre comparatif gzip, Brotli ou Zstandard : les algorithmes récents compressent le contenu dynamique plus vite à ratio comparable, et chaque milliseconde de compression économisée est une milliseconde de TTFB en moins.
Pourquoi mon TTFB est-il élevé côté serveur ?
Quatre causes dominent : un hébergement mutualisé aux ressources partagées, une version de PHP ancienne ou un OPcache mal dimensionné, des extensions qui travaillent en arrière-plan, et une base de données négligée. Le cumul de ces causes produit la majorité des TTFB dégradés que nous relevons en audit.
Une fois la requête arrivée, le chronomètre continue de tourner pendant que le serveur génère la réponse. Sur un CMS comme WordPress ou PrestaShop, cette génération enchaîne le démarrage de PHP, le chargement du cœur et des extensions, l’exécution du thème et des dizaines de requêtes vers la base de données.
La qualité de l’hébergement pèse ici de tout son poids : un mutualisé saturé, où des centaines de sites se partagent les mêmes processus PHP et la même base, produit des temps de réponse erratiques qu’aucune optimisation applicative ne rattrapera. Les fondations comptent tout autant : une version de PHP récente, un OPcache correctement dimensionné qui évite de recompiler le code à chaque requête, et un nombre de workers PHP adapté au trafic forment le socle sans lequel les autres optimisations ne sont que des rustines.
Le choix du type d’hébergement mérite d’être posé en connaissance de cause. Le mutualisé d’entrée de gamme optimise la densité de sites par machine, pas le temps de réponse de chacun ; les paramètres qui comptent (mémoire de PHP, réglages d’OPcache, configuration de la base) y sont figés et inaccessibles. Un VPS rend le contrôle mais transfère la responsabilité : les réglages décrits dans cet article sont alors à votre charge.
Les hébergements infogérés spécialisés, enfin, livrent ces réglages déjà faits, avec les couches de cache serveur intégrées. Il n’y a pas de réponse universelle, mais un critère simple : le TTFB de terrain, mesuré sur votre site réel, aux heures de votre trafic réel. Un hébergement se juge sur cette courbe, pas sur sa fiche tarifaire ni sur ses promesses.
Les plugins qui travaillent dans votre dos
Il existe une cause de TTFB dégradé que les audits front-end ne voient jamais : les tâches d’arrière-plan des plugins. Trois exemples reviennent constamment dans nos diagnostics. Le plugin Redirection journalise par défaut toutes les erreurs 404 et les redirections pendant une semaine : sur un site trafiqué, cela représente des dizaines de milliers d’écritures en base par jour, chacune exécutée sur le chemin critique de la requête du visiteur.
Broken Link Checker recrawle périodiquement tous les liens du site, occupant processeur et connexions sortantes. Wordfence, enfin, scanne l’arborescence de fichiers à intervalles réguliers, avec une pression disque et mémoire qui entre en concurrence directe avec les requêtes des visiteurs.
Aucun de ces comportements n’est un défaut : ce sont des réglages par défaut, presque toujours ajustables dans l’interface de chaque plugin. Réduire la rétention des journaux de Redirection, espacer les analyses de liens à un mois, activer le mode d’analyse à ressources limitées de Wordfence : ces trois réglages ne coûtent rien et suppriment une charge de fond permanente.
Le vrai danger est leur cumul : un site qui exécute simultanément ces trois processus subit en permanence l’un d’eux, et son TTFB moyen s’en ressent sur l’ensemble du trafic. C’est l’une des premières causes de TTFB dégradé inexpliqué sur des sites pourtant bien optimisés en façade : tout le travail front-end est fait, mais le serveur reste occupé à ses propres tâches.
La base de données, goulet d’étranglement silencieux
Tout en bas de la pile, la base de données fixe le plancher du temps de génération. Le paramètre le plus déterminant est le buffer pool d’InnoDB, la zone de RAM où MySQL et MariaDB conservent les données récemment lues : la documentation MariaDB en fait le premier réglage à examiner, car une valeur trop faible force des lectures disque à chaque requête.
Or la valeur par défaut, généralement 128 Mo, est rarement ajustée, y compris sur des serveurs disposant de plusieurs gigaoctets de mémoire : la base relit alors depuis le disque des données qui devraient vivre en RAM, et chaque page dynamique en paie le prix. S’y ajoutent les requêtes lentes des plugins mal conçus, qu’un outil comme Query Monitor permet d’attribuer précisément à leur responsable, extension par extension, hook par hook.
Deux autres postes méritent l’examen sur toute installation WordPress qui vieillit. Le premier est la table des options : chaque option marquée comme chargée automatiquement, un comportement documenté par la référence de la fonction add_option, est lue et désérialisée à chaque affichage de page. Les plugins désinstallés sans ménage y laissent des kilooctets, parfois des mégaoctets, de données chargées pour rien à chaque requête.
Le second est la fragmentation générale de la base : des tables de journaux jamais purgées, des révisions accumulées par milliers, des index absents sur les tables des extensions. Rien de tout cela ne se voit dans une interface, et tout cela s’additionne, requête après requête, dans le temps de génération.
wp-cron et les pics qui reviennent à heure fixe
Le planificateur de tâches de WordPress mérite une mention particulière, car son fonctionnement par défaut est contre-intuitif : les tâches planifiées, décrites dans le manuel des développeurs, ne s’exécutent pas à heure fixe mais au détour d’une visite. Quand une tâche est due, c’est la requête d’un visiteur réel qui la déclenche : ce visiteur paie, dans son propre TTFB, le coût de la sauvegarde, de l’envoi de newsletter ou du nettoyage qui se trouvait dans la file.
Sur les sites à trafic soutenu ou aux tâches lourdes, la parade classique consiste à désactiver ce déclenchement à la visite et à confier l’exécution à un vrai cron système, à intervalle régulier et hors du chemin des visiteurs :
// wp-config.php : ne plus déclencher les tâches à la visite
define( 'DISABLE_WP_CRON', true );
# crontab du serveur : exécution toutes les 5 minutes, hors trafic
*/5 * * * * curl -s https://www.exemple.fr/wp-cron.php?doing_wp_cron >/dev/null 2>&1Ce simple déplacement ne réduit pas la quantité de travail, mais il le sort du chemin critique : les tâches d’arrière-plan s’exécutent entre les visites, jamais pendant. Sur les courbes de TTFB de terrain, l’effet se lit immédiatement à la disparition des pics périodiques qui hachaient la distribution.
Votre site est-il aussi rapide que vos visiteurs l’espèrent ?
Comment le cache réduit-il le TTFB ?
En supprimant le travail plutôt qu’en l’accélérant. Une page servie depuis un cache de page ne réveille ni PHP ni la base de données ; servie depuis l’edge d’un CDN, elle n’atteint même pas votre serveur. On passe de centaines de millisecondes à quelques-unes, ce qu’aucun autre levier ne permet.
Tous les leviers précédents réduisent le coût du travail que le serveur effectue. Le cache, lui, supprime ce travail. C’est ce qui en fait, de très loin, le levier le plus puissant sur le TTFB : une page servie depuis un cache de page se dispense de PHP et de la base de données, une page servie depuis l’edge d’un CDN se dispense même du trajet jusqu’à votre serveur. Les ordres de grandeur changent de catégorie : on ne parle plus de grappiller des dizaines de millisecondes, mais de remplacer des centaines de millisecondes de génération par quelques millisecondes de lecture.
Le cache n’est pas pour autant un bouton unique : c’est un empilement de couches, chacune avec son périmètre et ses règles. Le navigateur conserve les ressources statiques, le CDN mutualise les réponses entre visiteurs, le cache de page évite la génération des pages anonymes, le cache objet (Redis, Memcached ou APCu) mémorise les requêtes SQL des pages qu’on ne peut pas cacher, l’OPcache conserve le code PHP compilé, et le buffer pool garde les données chaudes en mémoire.
Chaque couche protège celle d’en dessous, et une stratégie mûre les fait travailler ensemble : les en-têtes HTTP pilotent le navigateur et le CDN, les exclusions préservent les utilisateurs connectés, la purge maintient la fraîcheur à la publication. Nous avons consacré à cet empilement un guide complet du cache web, du navigateur à la base de données, qui détaille la configuration de chaque étage ; retenez ici l’essentiel : sur la plupart des sites au TTFB dégradé, la première question n’est pas « pourquoi le serveur est-il lent », mais « pourquoi ce travail n’est-il pas caché ».
Le profil du site détermine où porter l’effort. Un site éditorial ou vitrine, dont le trafic est massivement anonyme, tire l’essentiel de son gain du cache de page et de l’edge : bien réglé, son TTFB de terrain devient celui de son infrastructure de diffusion, plus celui de son application.
Une boutique en ligne ou un espace membre, où chaque visiteur porte une session, vit dans la situation inverse : ses pages sensibles échappent au cache de page, et c’est le cache objet, l’OPcache et la base qui décident du TTFB vécu. Les deux profils partagent en revanche un même piège : croire le cache actif parce qu’un plugin est installé. Seule la vérification des en-têtes servis, page par page et cookie par cookie, dit ce qui est réellement caché.
Pourquoi mon TTFB est-il élevé ?
Décomposez avant de conclure : si l’écart entre la fin du TLS et le premier octet domine, la cause est serveur ; si ce sont les étapes de connexion, la cause est réseau. Vérifiez ensuite si la page mesurée était cachée ou générée. Un TTFB moyen mélangeant les deux ne veut rien dire.
| Cause | Signe caractéristique | Correctif |
|---|---|---|
| Absence de cache de page | TTFB élevé et stable sur toutes les pages | Activer un cache de page ou un reverse proxy |
| Hébergement mutualisé | TTFB erratique, pics aux heures de pointe | Passer sur un serveur dédié ou un VPS |
| Chaîne de redirections | Écart important avant la requête elle-même | Rediriger en un seul saut, activer HSTS |
| Distance géographique | TTFB correct en local, mauvais à l’étranger | Placer un CDN devant le site |
| Tâches d’arrière-plan | Pics cycliques à heures régulières | Déplacer les crons hors du chemin visiteur |
| Base de données négligée | Lenteur sur les pages non cachées uniquement | Dimensionner le buffer pool, purger les journaux |
La colonne du milieu est celle qui fait gagner du temps. Chaque cause laisse une signature reconnaissable dans la distribution des mesures : un TTFB stable et haut n’a pas la même origine qu’un TTFB en dents de scie, et un écart entre visiteurs français et étrangers désigne immédiatement la distance plutôt que le serveur.
Face à un TTFB dégradé, la tentation est d’empiler les optimisations au hasard. La démarche rigoureuse consiste à décomposer, puis à isoler. Première étape : distinguer le réseau du serveur. Un outil aussi simple que curl fournit la décomposition complète depuis la ligne de commande :
curl -s -o /dev/null -w "DNS: %{time_namelookup}s
TCP: %{time_connect}s
TLS: %{time_appconnect}s
TTFB: %{time_starttransfer}s
Total: %{time_total}s
" https://www.exemple.fr/Si l’écart entre TLS et TTFB domine, le temps se perd côté serveur ; si ce sont les premières lignes qui pèsent, le problème est réseau (DNS lent, absence de CDN, redirections). Deuxième étape : vérifier ce que fait le cache. L’en-tête cf-cache-status d’un CDN, les en-têtes ajoutés par les plugins de cache, ou une simple comparaison entre une requête anonyme et une requête portant un cookie de session révèlent immédiatement si la page mesurée était servie depuis un cache ou générée à la demande : un TTFB moyen calculé en mélangeant les deux ne veut rien dire.
Troisième étape : répéter la mesure. Un TTFB isolé n’a aucune valeur statistique ; des mesures espacées sur plusieurs heures révèlent les motifs cycliques, ces pics réguliers qui trahissent une tâche planifiée, une sauvegarde ou un scan de sécurité, exactement le genre de cause qu’une mesure unique ne montrera jamais.
La dernière étape relie le symptôme à sa cause dans l’application elle-même : l’en-tête Server-Timing permet au serveur d’exposer ses temps internes (base de données, rendu, cache) directement dans les DevTools, et Query Monitor fait le même travail à l’intérieur de WordPress. À ce stade, le coupable a généralement un nom : une requête SQL, un plugin, un appel à une API externe effectué en pleine génération de page.
Par où commencer pour réduire son TTFB ?
Dans cet ordre : cache de page pour les visiteurs anonymes, CDN et en-têtes de cache, fondations d’exécution avec PHP et la base, puis charges parasites et réglages protocolaires. Ce classement suit le gain divisé par le risque de régression, et évite de polir les millisecondes avant les secondes.
Le diagnostic posé, l’ordre des travaux compte autant que les travaux eux-mêmes. Notre expérience converge vers une hiérarchie stable. Le premier chantier est toujours le cache de page pour les visiteurs anonymes : c’est lui qui change l’ordre de grandeur, et tout réglage fin effectué avant lui sera mesuré dans le bruit. Vient ensuite la diffusion : un CDN devant le site, des en-têtes de cache propres, et la vérification que le taux de hit est réellement au rendez-vous.
Le troisième chantier touche aux fondations d’exécution : version de PHP à jour, OPcache dimensionné, buffer pool de la base ajusté à la RAM disponible. Le quatrième s’attaque aux charges parasites : journaux de plugins, scans de sécurité, tâches planifiées déplacées hors du chemin des visiteurs. Le dernier, enfin, relève de la dentelle : compression adaptée au contenu dynamique, Early Hints, réglages protocolaires.
Cette hiérarchie n’a rien d’arbitraire : elle classe les leviers par gain attendu divisé par risque de régression, et elle évite le travers classique qui consiste à polir les millisecondes pendant que les centaines de millisecondes attendent.
Un mot sur ce que ce plan ne contient pas : les optimisations front-end. Minifier le JavaScript, différer les scripts ou optimiser les images n’a aucun effet sur le TTFB, qui est entièrement consommé avant le premier octet de HTML. L’inverse n’est pas vrai : un TTFB assaini rend chaque optimisation front-end plus visible, puisque toute la cascade démarre plus tôt. C’est l’ordre naturel d’un chantier de performance : le serveur d’abord, le rendu ensuite.
Quel est l’impact du TTFB sur le LCP ?
Le TTFB constitue la première des quatre sous-parties du LCP : tant que le HTML n’est pas arrivé, le navigateur ignore quelles ressources charger. Réduire le TTFB de 500 ms avance toute la cascade de 500 ms, et donc le FCP, le LCP et l’interactivité.
Le TTFB n’est jamais une fin en soi : vos visiteurs ne perçoivent pas des octets, ils perçoivent une page qui s’affiche. Mais sa position en tête de chaîne lui donne un effet démultiplié. Le HTML est la ressource dont découlent toutes les autres : tant qu’il n’est pas arrivé, le navigateur ne connaît ni les styles, ni les scripts, ni les images à charger. Réduire le TTFB de 500 ms, c’est avancer de 500 ms le départ de toute la cascade de chargement, et donc, mécaniquement, le FCP, le LCP et l’interactivité. Peu de leviers de performance offrent cette propriété : un gain sur le TTFB se propage à toutes les métriques de chargement en aval.
Vos visiteurs humains ne sont d’ailleurs pas les seuls concernés. Les robots d’indexation subissent le même premier octet, et Google indique dans sa documentation sur le budget d’exploration qu’un site qui répond rapidement permet à Googlebot d’explorer davantage de pages, quand des temps de réponse qui s’allongent le font ralentir la cadence. Sur les sites volumineux, un TTFB dégradé se paie donc deux fois : une expérience utilisateur amoindrie, et une fraîcheur d’indexation qui s’étiole.
C’est aussi ce qui rend son diagnostic si rentable : les causes d’un TTFB élevé (cache absent, hébergement sous-dimensionné, base négligée, tâches d’arrière-plan) sont précisément celles qui finiront par dégrader le reste du site. Si votre TTFB de terrain dépasse les 800 ms recommandées, la chaîne complète mérite un examen, des en-têtes HTTP au buffer pool. C’est le cœur de notre métier d’optimisation de la web performance : remonter la chaîne du premier octet, mesurer chaque maillon, et rendre au serveur ce qui appartient au cache. Votre LCP, et vos visiteurs, en verront la différence dès le premier octet.
