Comprendre et mesurer le TTFB (Time to First Byte)
Découvrez ce qu'est le TTFB, ses seuils et comment le mesurer pour servir votre HTML plus vite et accélérer toutes vos métriques de chargement.
Le TTFB (Time to First Byte), ou délai avant le premier octet, mesure le temps écoulé entre la demande d’une ressource et l’arrivée du premier octet de la réponse. C’est une métrique fondamentale pour évaluer le temps de configuration de la connexion et la réactivité du serveur. Pour une requête de navigation, c’est-à-dire la demande d’un document HTML, le TTFB précède toutes les autres métriques de chargement.
Pour le SEO, soigner le TTFB est stratégique : tant que le serveur n’a pas livré le premier octet, rien ne peut s’afficher côté navigateur. Un TTFB faible permet d’envoyer le balisage au plus tôt, ce qui accélère mécaniquement le FCP et le LCP. À l’inverse, un serveur lent à répondre plombe toute l’expérience de chargement. Une fois la mesure en place, les leviers détaillés dans notre guide pour optimiser le TTFB permettent d’abaisser durablement ce délai.
Le TTFB est le point de départ de toute la chaîne, et pourtant c’est celui qu’on examine en dernier. Mon principe : tant que le serveur tarde à livrer le premier octet, aucune optimisation côté navigateur ne rattrapera le retard. Avant de toucher aux images ou au JavaScript, regardez ce que fait votre serveur, c’est souvent là que se cache le vrai gain.
Les phases qui composent le TTFB
Le TTFB n’est pas un bloc unique : il correspond à la somme de plusieurs phases successives. Comprendre ces phases aide à savoir où agir, qu’il s’agisse de la couche réseau ou du backend. Réduire la latence au moment de la configuration de la connexion et côté serveur fait baisser le TTFB.
| Phase | Description |
|---|---|
Redirection |
Durée des éventuelles redirections avant d’atteindre la ressource |
Service worker |
Temps de démarrage du service worker, le cas échéant |
Résolution DNS |
Traduction du nom de domaine en adresse |
Connexion et TLS |
Établissement de la connexion et négociation sécurisée |
Requête |
Temps jusqu’à l’arrivée du premier octet de la réponse |
Les seuils du TTFB selon Google
Comme le TTFB précède des métriques centrées sur l’utilisateur comme le FCP et le LCP, Google recommande de configurer votre serveur pour que le 75e centile des utilisateurs bénéficie d’un FCP dans la plage « bon ». Pour situer ce délai dans l’ensemble des signaux d’expérience de page, il est utile de comprendre les Core Web Vitals. À titre indicatif, la plupart des sites devraient viser un TTFB de 0,8 seconde ou moins.
| Évaluation | Valeur du TTFB | Signification |
|---|---|---|
Bon |
0,8 seconde ou moins |
Serveur réactif, balisage envoyé rapidement |
À améliorer |
Entre 0,8 et 1,8 seconde |
Réactivité serveur perfectible |
Médiocre |
Plus de 1,8 seconde |
Réponse serveur trop lente, chargement pénalisé |
Un guide approximatif à nuancer
Le TTFB n’étant pas une métrique Core Web Vitals, il n’est pas indispensable d’atteindre absolument le seuil « bon », tant que cela n’empêche pas d’obtenir de bons scores sur les métriques essentielles. La façon de diffuser le contenu compte beaucoup : une application monopage qui remplit son balisage avec du JavaScript a tout intérêt à viser le TTFB le plus bas possible, alors qu’un site rendu côté serveur peut afficher un TTFB plus élevé tout en offrant de meilleurs FCP et LCP. Ces seuils sont donc un repère à mettre en balance avec votre architecture.
Avec quels outils mesurer le TTFB
Le TTFB se mesure sur le terrain comme en laboratoire. Il s’applique d’ailleurs à toutes les requêtes, pas seulement à la navigation : les ressources hébergées sur d’autres origines peuvent introduire de la latence liée à l’ouverture de nouvelles connexions. Le même panneau réseau vous sert d’ailleurs à mesurer le FCP, qui suit directement le premier octet.
| Outil | Type de mesure | Usage |
|---|---|---|
Rapport sur l’expérience utilisateur Chrome (CrUX) |
Terrain |
Données réelles agrégées |
Bibliothèque JavaScript web-vitals |
Terrain |
Mesure dans le code, sur vos utilisateurs |
Panneau réseau des outils pour développeurs Chrome |
Laboratoire |
Analyse requête par requête |
WebPageTest |
Laboratoire |
Test détaillé multi-localisations |
Mesurer le TTFB en JavaScript
Pour mesurer le TTFB des requêtes de navigation, vous pouvez utiliser l’API Navigation Timing via un PerformanceObserver qui écoute l’entrée navigation et lit la valeur responseStart. La bibliothèque web-vitals propose une approche plus concise et gère les cas particuliers à votre place.
new PerformanceObserver((entryList) => {
const [pageNav] = entryList.getEntriesByType('navigation');
console.log(`TTFB: ${pageNav.responseStart}`);
}).observe({
type: 'navigation',
buffered: true
});Le TTFB des ressources servies depuis une autre origine ne sera pas mesurable sur le terrain si ces serveurs ne définissent pas l’en-tête Timing-Allow-Origin. Certaines ressources mises en cache peuvent aussi renvoyer une valeur de 0. Tenez-en compte pour ne pas tirer de fausses conclusions.
À faire
- viser 0,8 seconde ou moins
- réduire les redirections
- soigner la réactivité du backend
- mettre en cache au plus près de l’utilisateur
- mesurer au 75e centile
À éviter
- enchaîner les redirections inutiles
- négliger la résolution DNS et la négociation TLS
- juger le TTFB sans tenir compte de votre mode de rendu
- ignorer les ressources multi-origines
Points clés à retenir
- Visez un TTFB de 0,8 seconde ou moins
- Limitez les redirections et la latence serveur
- Mettez en cache le contenu au plus près des utilisateurs
- Adaptez votre lecture du seuil à votre architecture de rendu
- Mesurez sur le terrain et en laboratoire pour croiser les angles
Le TTFB conditionne la rapidité d’envoi du HTML et donc toutes les métriques suivantes.
Quiz : testez vos connaissances
Quiz : testez vos connaissances
-
Le TTFB correspond-il à un bloc unique ?
- Non, il est la somme de plusieurs phases successives, côté réseau et côté backend
- Non, mais il ne concerne que la couche réseau, jamais le backend
- Oui, c'est une seule durée indivisible mesurée par le serveur
Le TTFB additionne plusieurs phases, comme la configuration de la connexion et le temps de réponse du serveur. Comprendre ces phases aide à savoir où agir pour le réduire.
-
Vers quelle valeur cible se situe un bon TTFB selon le guide approximatif ?
- 0,1 seconde ou moins, sur l'ensemble des visites
- 0,8 seconde ou moins, mesuré au 75e centile
- 2,5 secondes ou moins, mesuré en moyenne
Le guide indique de viser 0,8 seconde ou moins au 75e centile. Comme le TTFB n’est pas un Core Web Vital, ce seuil reste une indication à pondérer selon le mode de rendu.
-
Pourquoi le TTFB des ressources servies depuis une autre origine peut-il être impossible à mesurer sur le terrain ?
- Parce que ces serveurs ne définissent pas toujours l'en-tête Timing-Allow-Origin
- Parce que les ressources tierces n'ont jamais de TTFB
- Parce que le TTFB ne s'applique qu'aux requêtes de navigation
Sans l’en-tête
Timing-Allow-Originrenvoyé par le serveur tiers, le TTFB de la ressource multi-origine n’est pas mesurable sur le terrain.
À propos de l'auteur
Besoin d'un accompagnement SEO ?
Un serveur lent à répondre freine tout votre site ? Évaluons votre TTFB et les leviers pour l'abaisser.