Optimiser le TTFB : accélérer la réponse de votre serveur

Le TTFB (Time to First Byte) correspond au temps qui s’écoule entre la requête du navigateur et l’arrivée du premier octet de la réponse du serveur. Comme il précède le FCP (First Contentful Paint) et le LCP (Largest Contentful Paint), un TTFB élevé pénalise mécaniquement toutes les métriques d’expérience utilisateur qui suivent. En SEO, ce signal compte : un serveur lent retarde l’affichage, dégrade la perception de vitesse et peut freiner l’exploration de vos pages. Pour bien cerner ce que recouvre cet indicateur, commencez par comprendre et mesurer le TTFB.

Le TTFB n’est pas une métrique Core Web Vitals à proprement parler, mais il reste un point de départ déterminant. La règle générale recommandée par Google est de viser 0,8 seconde ou moins, afin que le 75e centile de vos visiteurs bénéficie d’un bon FCP. Ce seuil reste indicatif : un site rendu côté serveur peut afficher un TTFB plus haut tout en obtenant d’excellents FCP et LCP, alors qu’une application monopage a tout intérêt à viser le TTFB le plus bas possible pour déclencher plus tôt le rendu côté client.

Avant toute optimisation, observez l’impact réel sur vos visiteurs. Les données de terrain sont votre source principale, car elles intègrent les redirections, contrairement aux outils de laboratoire qui mesurent souvent l’URL finale. PageSpeed Insights affiche le TTFB des utilisateurs réels dans la section haute du rapport, tandis que les problèmes de laboratoire apparaissent dans l’analyse Latence des requêtes de document.

Gardez en tête que l’audit du temps de réponse serveur de Lighthouse exclut la résolution DNS et les redirections : il ne représente donc qu’une partie du TTFB. Pour aller plus loin, l’en-tête de réponse Server-Timing permet de décomposer le travail du backend (base de données, rendu côté serveur, accès disque, succès ou échecs de cache CDN) et de remonter ces durées sur le terrain comme en laboratoire.

Lorsque le TTFB de laboratoire est bien plus élevé que celui du terrain, l’environnement de test est simplement plus contraint que l’expérience réelle : les recommandations restent valables, mais leur impact peut être exagéré. À l’inverse, un TTFB de terrain nettement supérieur au laboratoire révèle des problèmes invisibles en test, comme une mise en cache côté serveur, des redirections ou des différences de réseau.

Pour vérifier si le cache fausse vos mesures, testez des pages peu consultées ou ajoutez un paramètre d’URL afin d’obtenir du contenu non mis en cache. Prévoyez toujours un moyen de contourner le CDN et les couches de cache, par exemple via un paramètre d’URL dédié, pour mesurer le temps serveur réel perçu par certains utilisateurs.

L’optimisation du TTFB dépend fortement de votre pile backend, qui varie d’un site à l’autre. Plutôt que de viser une technologie précise, concentrez-vous sur les leviers qui s’appliquent à la majorité des architectures. Le tableau ci-dessous synthétise les actions les plus efficaces et leur rôle. Au-delà du CDN, pensez aussi à anticiper les connexions réseau vers les origines tierces critiques.

Les navigateurs traitent le balisage en flux, par blocs, à mesure qu’il arrive du serveur. Maintenez ce flux : si le backend ralentit l’envoi des premiers octets, le rendu attend inutilement. Les frameworks modernes comme les versions récentes de React proposent un rendu côté serveur en streaming, et le rendu statique (fichiers HTML générés à la compilation) permet au serveur d’envoyer la réponse immédiatement. Notre guide pour optimiser la réponse HTML du serveur détaille comment préserver ce flux de bout en bout.

Pour les sites dont le backend effectue un travail important avant de produire le balisage, l’en-tête 103 Early Hints indique au navigateur de précharger les ressources essentielles au rendu pendant cette préparation. Attention toutefois : comme le cache, ces optimisations peuvent masquer un serveur réellement lent, d’où l’importance de continuer à mesurer le temps serveur réel.