Comment repérer et corriger un TTFB lent (Time to First Byte)

Comment repérer et corriger un TTFB lent ?

Commencez par les field data : confirmez que le TTFB est lent et sur quel appareil, identifiez la plus lente de ses cinq parties ainsi que les visiteurs et les pages qui ralentissent, puis regardez côté serveur. Corrigez ce que ce diagnostic met en évidence.

Ces cinq parties sont waiting, cache, DNS, connection et request, et le guide Time to First Byte détaille ce que chacune recouvre.

Comment vérifier et tester votre TTFB ?

Vérifiez gratuitement votre TTFB dans PageSpeed Insights : il indique le TTFB constaté par vos visiteurs sur Chrome au cours des 28 derniers jours, sous « Autres métriques notables », pour l'URL et pour le site entier, sur l'onglet mobile et desktop. « La première étape de la guérison consiste à admettre qu'on a un problème. » Search Console ne proposant aucun rapport TTFB, ces field data sont le seul endroit pour savoir si vous en avez un.

Le rapport Core Web Vitals issu de l'historique CrUX, gratuit, affiche ce TTFB sur 28 jours sous forme d'un point par semaine sur les 25 dernières semaines, pour tout domaine ou URL avec suffisamment de visiteurs sur Chrome. Un site qui en a trop peu n'aura de field data dans aucun des deux outils : testez alors un chargement dans Chrome et mesurez chaque visite avec le RUM.

CrUX, TTFB sur mobile par semaine pour une grande boutique en ligne : au-dessus de la ligne des 0,8 s chaque semaine.

Un outil de test ou de vérification du TTFB en ligne envoie une seule requête depuis son propre serveur : un chargement unique, dont la valeur dépend de l'emplacement de ce serveur, de la présence de la page en cache et de la prise en compte des redirections. PageSpeed Insights fournit le 75e percentile de 28 jours de visites réelles. curl envoie cette même requête depuis votre propre machine :

curl -s -o /dev/null -w "%{time_starttransfer}\n" https://www.example.com/

Le résultat correspond au TTFB de cette requête en secondes ; ajoutez -L pour suivre les redirections. Utilisez un outil de test ou curl pour comparer la même URL en cache et hors cache, ou avant et après un changement.

Le TTFB n'est pas un Core Web Vital, mais un TTFB lent peut faire échouer l'évaluation des Core Web Vitals via le Largest Contentful Paint (LCP), car l'attente du HTML constitue la première étape de chaque LCP.

Où Chrome affiche-t-il le TTFB d'un chargement de page ?

Dans Chrome DevTools, l'onglet Timing du panneau Network décompose le chargement du document HTML en plusieurs étapes ; le TTFB de ce chargement s'étend jusqu'à la fin de « Waiting for server response ». L'onglet Headers indique si la page provient d'un cache (cf-cache-status: HIT sur Cloudflare, en-tête x-cache chez de nombreux hébergeurs).

1. Ouvrez la page dans une fenêtre de navigation privée (déconnecté, panier vide), ouvrez le panneau Network dans DevTools et rechargez.
2. Cliquez sur le document HTML, la première ligne de type document. Une redirection préalable s'affiche sur sa propre ligne.
3. Dans Headers, repérez l'en-tête de cache. HIT signifie que le cache a répondu ; MISS ou BYPASS signifie que ce cache a transmis la requête à votre serveur.
4. Chargez la même URL avec ?gclid= et une valeur encore jamais utilisée, à l'image d'un clic Google Ads. Un statut MISS et une attente plus longue indiquent que les visiteurs issus des annonces contournent le cache.

Un MISS au niveau du CDN avec un temps d'attente tout aussi court signifie qu'un second cache situé derrière a répondu, généralement le cache de page de votre serveur. Sur Cloudflare, la valeur DYNAMIC sur le HTML signifie que Cloudflare transmet chaque requête de page à votre serveur : il ne met le HTML en cache que si une Cache Rule le lui demande, ou via Automatic Platform Optimization, son extension pour WordPress.

Collé dans la console, cet extrait mesure le TTFB et ses cinq parties via l'API Navigation Timing, selon la formule de la bibliothèque web-vitals de Google, afin que la somme des parties corresponde exactement au TTFB :

new PerformanceObserver((list) => {
  const [nav] = list.getEntries();
  const at = (t) => Math.max(t - (nav.activationStart || 0), 0);
  const ttfb = at(nav.responseStart);
  const waiting = at(nav.workerStart || nav.fetchStart);
  const cache = at(nav.domainLookupStart) - waiting;
  const dns = at(nav.connectStart) - at(nav.domainLookupStart);
  const connection = at(nav.connectEnd) - at(nav.connectStart);
  const request = ttfb - at(nav.connectEnd);
  console.table({ ttfb, waiting, cache, dns, connection, request });
}).observe({ type: 'navigation', buffered: true });

Le guide Time to First Byte fournit la version avec bibliothèque à intégrer dans votre propre code.

Server-Timing est un en-tête de réponse dans lequel le serveur transmet ses propres temps d'exécution pour ce même chargement, à raison d'une entrée par étape :

Server-Timing: wp;dur=27.8;desc="WordPress and query", tpl;dur=27.1;desc="Template"

DevTools liste ces entrées sous Server Timing dans ce même onglet Timing, sous « Waiting for server response », la partie du TTFB que traite le guide Request duration ; cette page fournit le code permettant d'envoyer l'en-tête depuis PHP et Node.

Un chargement d'une page WordPress sur une installation locale de test : les deux entrées Server-Timing s'inscrivent dans les 59 ms passées par le navigateur à attendre le serveur.

Pourquoi faut-il des données réelles pour identifier un TTFB lent ?

PageSpeed Insights fournit un seul TTFB par type d'appareil pour 28 jours de visites, sans préciser quels visiteurs ou quelle partie causent la lenteur. DevTools et les outils de test chargent l'URL finale depuis un point géographique unique, alors que les vrais visiteurs arrivent via des redirections, depuis des pays éloignés, connectés ou avec des paramètres de tracking. Le Real-user monitoring (RUM) enregistre le TTFB de chaque chargement de page avec l'ensemble de ces détails.

J'ai développé CoreDash exactement pour cela : obtenir le TTFB de chaque chargement de page, décomposé par partie et par visiteur. Ajoutez son script à vos pages ou installez son plugin WordPress. Trois segments, correspondant aux informations visiteurs selon lesquelles CoreDash découpe les données, restent vides tant que votre site ne les envoie pas :

• Logged in status : attribuez la valeur 1 ou 0 à window.__CWVLI avant le script CoreDash, ou activez « Tag login status » dans le plugin WordPress.
• Page label : window.__CWVL attribue un libellé à la page (comme son template), afin que les pages produit, la recherche et le checkout disposent chacune de leur propre TTFB.
• Release : enregistrez chaque déploiement dans CoreDash depuis votre CI.

Que noter avant de modifier quoi que ce soit ?

Notez la date, le TTFB au 75e percentile sur mobile et sur desktop, ses cinq parties, ainsi que le TTFB de vos principaux groupes de pages et segments de visiteurs. Après une modification, comparez le même nombre de jours avant et après, afin que les jours de semaine et le week-end figurent dans les deux périodes. Le rapport Core Web Vitals conserve pour vous la courbe hebdomadaire CrUX.

Le TTFB est-il lent pour tout le monde ou pour certains visiteurs ?

Segmentez d'abord par partie, puis par visiteur. Quand tous les groupes sont lents, l'une des cinq parties est trop longue pour l'ensemble d'entre eux. À l'inverse, si un seul groupe est bien plus lent que les autres, il contourne le cache de page ou emprunte un chemin plus long vers la page.

Lent pour tout le monde : quelle est la plus longue des cinq parties ?

Un temps de request excessif est la cause la plus fréquente d'un TTFB lent : le serveur met trop de temps à générer la page, et cette partie comprend également un aller-retour sur le réseau. Sur 82 des 86 sites CoreDash ayant enregistré au moins 1 000 chargements de page sur mobile au cours des 28 jours précédant le 9 novembre 2026, la request représentait la plus grande part du TTFB au 75e percentile.

Dans CoreDash, ouvrez le TTFB sur mobile et regardez Phase breakdown.

CoreDash, TTFB sur mobile décomposé en cinq parties sur acme-pagespeed.com : repérez la barre la plus longue, ici Request.

Lent pour certains visiteurs : quel groupe, et qu'est-ce que cela signifie ?

Comparez le TTFB de chaque groupe de visiteurs avec le reste du trafic. Un groupe nettement plus lent contourne généralement le cache de page, passe par une redirection ou provient d'un pays éloigné. La mise en cache est souvent désactivée ou ignorée pour les utilisateurs connectés, les pages de panier, les requêtes contenant des paramètres Google Ads, les résultats de recherche et le checkout.

Sur les sites mesurés avec CoreDash, les chargements sur mobile passés par une redirection affichaient un TTFB d'environ 1 seconde au 75e percentile sur les 28 jours précédant le 10 novembre 2026, contre 0,63 seconde sans redirection. Sur 23 des 27 sites enregistrant suffisamment de chargements dans les deux groupes, le TTFB était plus élevé avec la redirection. Les chargements en session connectée et ceux comportant un paramètre de tracking étaient également plus lents sur la plupart des sites.

Dans CoreDash, le tableau de la page TTFB regroupe les données par segment ci-dessous ; cliquer sur une valeur filtre toute la page, répartition comprise.

CoreDash, TTFB regroupé par Redirect Count sur acme-pagespeed.com : comparez le p75 de chaque groupe avec la ligne sans redirection.

Facebook ajoute un nouveau fbclid à chaque clic sur un lien sortant, publicités incluses : chaque visiteur provenant de Facebook risque donc de rater le cache. Ce sont les coupables habituels ; chaque site ayant aussi ses spécificités, comparez également vos page labels.

Comment corriger ce que vous avez trouvé ?

Réduisez la plus importante des cinq parties du TTFB pour les visiteurs qui la subissent. Commencez par faire en sorte que chaque page qui peut être mise en cache provienne du cache pour tous les visiteurs : déconnectés, avec un paramètre de tracking ou après une redirection. Éliminez ensuite les redirections et mettez le HTML en cache sur un CDN, puis accélérez le serveur pour les pages qui ne peuvent pas être mises en cache.

• WordPress : un cache de page dans WP Rocket, LiteSpeed Cache ou chez votre hébergeur, ou avec le plugin de ce site, WP Core Web Vitals, qui sert la page en cache avant le chargement de WordPress. Testez-le en étant déconnecté et vérifiez qu'il ignore les paramètres de tracking : WP Rocket ignore par défaut gclid, fbclid et les paramètres utm_, LiteSpeed Cache propose le réglage Drop Query String, et un CDN a besoin de sa propre règle. Pour les pages WooCommerce et les utilisateurs connectés, utilisez un cache d'objets comme Redis, souvent activable en un clic chez votre hébergeur ; Query Monitor liste les requêtes lentes et le plugin dont elles proviennent.
• Shopify : le serveur, son cache et le CDN sont du ressort de Shopify. Les redirections, les applications et le code Liquid de votre thème sont de votre responsabilité : Shopify Theme Inspector pour Chrome montre quelle partie du thème est lente à s'exécuter sur le serveur ; transmettez cette partie à la personne qui gère votre thème.
• Votre propre serveur ou un hébergeur : demandez la mise en cache du HTML sur le CDN, l'exclusion des paramètres de tracking de la clé de cache, la suppression de la redirection, ainsi que l'activation de Server-Timing (les mesures propres au serveur par étape) sur le template lent.

Le guide Time to First Byte détaille le correctif par cause, avec le code.

Les 103 Early Hints, que Shopify envoie et que Cloudflare prend en charge, réduisent le TTFB mesuré : Chrome considère le code 103 comme le premier octet, alors que le HTML n'arrive pas plus vite pour autant. De même, un plugin de cache peut être activé alors que la majorité des visiteurs le contourne : un cookie présent sur chaque réponse, pour une session ou un test A/B, exclut souvent la page du cache. L'en-tête de cache le montre : BYPASS ou MISS, même en étant déconnecté.

La correction du TTFB a-t-elle fonctionné ?

Vérifiez d'abord le cache, puis les field data. L'en-tête de réponse doit afficher un cache hit en étant déconnecté et avec une nouvelle valeur ?gclid= ; le RUM indique le nouveau TTFB par groupe de visiteurs dès le lendemain ; PageSpeed Insights et le rapport Core Web Vitals évoluent sur les quatre semaines suivantes.

Comparez les mêmes groupes que ceux notés avant la modification. Sur la courbe hebdomadaire CrUX, une correction — ou un déploiement qui a dégradé les choses — se traduit par une évolution sur environ quatre semaines ; vérifiez ce qui est passé en production la semaine où le changement commence.

Parfois, le groupe ralenti pointe vers un élément auquel vous n'avez pas accès : un cache chez l'hébergeur, une API attendue par la page, une règle CDN configurée il y a des années. Lors d'une Core Web Vitals power hour, nous prenons votre groupe de visiteurs le plus lent, analysons l'un de ses chargements de page à travers les en-têtes de réponse et les timings du serveur, puis convenons des modifications à apporter et de qui s'en charge.