Time to First Byte (TTFB) : définition, causes, optimisation

Qu'est-ce que le Time to First Byte (TTFB) ?

Le Time to First Byte (TTFB), ou temps jusqu'au premier octet, est le temps entre le début d'une navigation et l'arrivée dans le navigateur du premier octet de la réponse. Il inclut les redirections, le démarrage du service worker, la résolution DNS, la connexion et la négociation TLS, la requête et le temps de traitement du serveur. Rien ne peut s'afficher avant.

Le TTFB n'est pas un Core Web Vital, mais il précède le First Contentful Paint et le Largest Contentful Paint : une réponse lente laisse moins de marge au LCP pour tout le reste. La définition de référence figure dans le guide TTFB de web.dev (en anglais).

Ce qui compose le TTFB

Le traitement serveur est généralement la partie que vous maîtrisez le plus. La distance au serveur (la latence réseau) est la partie qu'un CDN améliore.

Seuils du TTFB

Google l'évalue au 75e centile des chargements réels. web.dev présente 0,8 seconde comme un repère approximatif, pas une règle stricte. Une page rendue côté serveur avec un TTFB plus élevé peut avoir un bon LCP, alors qu'une application rendue côté client dépend davantage d'une réponse rapide.

Un exemple chiffré

Avec des chiffres illustratifs, la page produit d'une boutique affiche 120 ms pour le DNS, la connexion et le TLS réunis, et 40 ms pour le retour de la réponse, mais le serveur met 900 ms à construire le HTML parce qu'il enchaîne 30 requêtes en base. Le TTFB atteint environ 1,06 s et le LCP ne peut pas faire mieux. Mettre le HTML rendu en cache à la périphérie quelques instants, ou ramener les requêtes à quelques-unes bien indexées, supprime l'essentiel de ces 900 ms. La partie réseau change à peine. C'est pourquoi on décompose le TTFB en phases avant d'optimiser.

Comment mesurer le TTFB

Dans le navigateur, la Navigation Timing API le fournit directement. responseStart est mesuré depuis le début de la navigation : il inclut donc déjà redirections, DNS et handshake :

new PerformanceObserver((list) => {
  const [nav] = list.getEntriesByType('navigation');
  console.log('TTFB:', nav.responseStart, 'ms');
}).observe({ type: 'navigation', buffered: true });

En ligne de commande, curl détaille chaque phase. time_starttransfer est le temps écoulé depuis le début jusqu'à la réception du premier octet :

curl -o /dev/null -s -w "dns: %{time_namelookup}s\nconnect: %{time_connect}s\ntls: %{time_appconnect}s\nttfb: %{time_starttransfer}s\ntotal: %{time_total}s\n" https://example.com

Vous pouvez aussi utiliser le test de vitesse de site LoadFocus ou consulter des données d'utilisateurs réels avec le vérificateur de Core Web Vitals. Les outils de laboratoire montrent un chargement depuis un seul endroit. Les données de terrain issues du real user monitoring ou du Chrome UX Report montrent ce que vivent vraiment vos visiteurs, redirections comprises.

Comment réduire le TTFB

• Servir les pages cacheables depuis un CDN. Un réseau de diffusion de contenu répond depuis un serveur proche du visiteur, avec des en-têtes Cache-Control adaptés. Les pages personnalisées ne se mettent pas en cache ainsi.
• Supprimer les redirections. Corrigez les liens qui passent de http à https, par un www manquant ou une barre oblique finale. Chacune coûte un aller-retour.
• Accélérer le backend. Ajoutez des index en base, éliminez les requêtes N+1, mettez en cache les résultats coûteux et évitez d'attendre des appels tiers lents.
• Diffuser en streaming ou prérendre. Envoyez le HTML par morceaux pendant sa génération, ou produisez des pages statiques au déploiement quand elles n'ont pas besoin d'être personnalisées.
• Utiliser 103 Early Hints. Le navigateur peut charger les ressources critiques pendant qu'un backend lent termine sa réponse.
• Mesurer le backend avec Server-Timing. L'en-tête expose, par requête, les temps de base de données, de rendu et d'échec de cache.

Erreurs courantes

• Ne mesurer que la réponse en cache. Le cache et Early Hints peuvent masquer une origine lente. Testez une URL sans cache pour voir le vrai temps serveur.
• Prendre responseStart - requestStart pour le « TTFB ». Cela omet redirections, DNS et handshake, et sous-estime l'attente des utilisateurs.
• Juger sur un seul test de laboratoire. Le TTFB varie selon le lieu et la charge. Regardez le 75e centile sur de nombreuses visites.
• Ignorer les démarrages à froid. Une fonction serverless ou un conteneur inactif peut retarder fortement la première requête après une période calme.
• Supposer que le TTFB tient sous charge. Une page qui répond en 300 ms à un visiteur peut mettre plusieurs secondes quand des centaines arrivent ensemble.

TTFB, tests de charge et monitoring

Le traitement serveur étant la partie variable, le TTFB est sensible au trafic. Les tests de charge LoadFocus sollicitent votre site ou votre API depuis plus de 25 régions cloud et montrent les temps de réponse à mesure que les utilisateurs simultanés augmentent, pour voir si le backend se dégrade avant l'arrivée du trafic réel. Page Speed Monitoring répète des audits Lighthouse planifiés depuis 25 régions : une dégradation du TTFB après un déploiement apparaît alors comme une tendance. Pour une routine de monitoring incluant les Core Web Vitals, lisez (en anglais) how to monitor Core Web Vitals with alerts and reports.

Questions fréquentes : Time to First Byte

Quel est un bon TTFB ?

0,8 seconde ou moins au 75e centile est jugé bon, et plus de 1,8 seconde mauvais. Prenez 0,8 s comme repère : ce qui compte au final, c'est que FCP et LCP soient bons pour vos visiteurs.

Le TTFB est-il un Core Web Vital ?

Non. Les Core Web Vitals sont le LCP, l'INP et le CLS. Le TTFB est une métrique de diagnostic qui explique une partie d'un LCP ou d'un FCP lent.

Comment un CDN améliore-t-il le TTFB ?

Il répond aux requêtes cacheables depuis un serveur proche du visiteur, ce qui raccourcit la connexion et évite le trajet jusqu'à l'origine. Il n'aide pas pour les réponses générées par utilisateur, sauf si le CDN peut les mettre en cache ou exécuter la logique en périphérie.

Pourquoi le TTFB diffère-t-il entre outils de laboratoire et données de terrain ?

Un outil de laboratoire mesure un chargement depuis un lieu sur un réseau fixe. Les données de terrain couvrent de vrais visiteurs, avec leurs redirections, leurs appareils et leur distance à vos serveurs : les deux concordent rarement.

Quelle différence entre TTFB et temps de réponse du serveur ?

Le temps de réponse du serveur ne couvre que le travail du backend. Le TTFB inclut aussi redirections, DNS, connexion, TLS et trajet réseau, et peut être bien plus grand pour des visiteurs éloignés.