Time to first byte (TTFB) : ce qui est bon et comment le réduire

Le time to first byte (TTFB) est le délai entre le début de la navigation et le premier octet de la réponse HTML. Web.dev, de Google, considère qu’une valeur de 0,8 seconde ou moins est bonne et qu’au-delà de 1,8 seconde elle est mauvaise, mesurées au 75e percentile des visites réelles (web.dev, dernière mise à jour en novembre 2025). Le TTFB n’est pas une Core Web Vital, mais toutes les métriques suivantes, dont First Contentful Paint et Largest Contentful Paint, commencent après lui. Sur mobile, c’est aussi là que s’additionnent les redirections, le DNS, le TLS et un serveur lent, parce que chacune de ces étapes coûte au moins un aller-retour sur le réseau mobile.

Qu’est-ce que le time to first byte ?

Le TTFB est la somme de toutes les étapes qui précèdent l’arrivée du premier octet du document, y compris les redirections, le DNS et le TLS. Selon web.dev, il comprend :

• le temps de redirection ;
• le démarrage du service worker, si le site en a un ;
• la recherche DNS ;
• la connexion et la négociation TLS ;
• la requête elle-même, jusqu’au premier octet de la réponse.

C’est pourquoi un serveur rapide peut afficher un TTFB lent. Une visite qui commence sur http://example.com, redirige vers https://example.com puis vers https://www.example.com a payé deux redirections et trois connexions avant que le serveur de la page finale n’ait fait quoi que ce soit.

Le TTFB n’est pas non plus le « temps de réponse du serveur » des anciens rapports Lighthouse. Cet audit ne mesurait que l’attente du document principal et excluait les recherches DNS et les redirections ; c’est donc une partie du TTFB (Chrome for Developers).

Quel est un bon TTFB ?

Un bon TTFB est de 0,8 seconde ou moins, et web.dev appelle ses seuils « une indication approximative », pas une exigence. Voici les plages à novembre 2025, avec le chiffre plus strict de Lighthouse :

Les deux chiffres mesurent des choses différentes. Les 600 ms de Lighthouse couvrent le temps de réponse propre du serveur, tandis que le guide des 0,8 s couvre le TTFB complet ; une même page peut donc réussir l’un et échouer à l’autre. Ce sont deux seuils de conception fixés par Google.

À quelle fréquence obtient-on un bon score sur mobile ? Dans le Web Almanac 2025 de HTTP Archive, fondé sur les données de juillet 2025, 44 % des sites mobiles avaient un bon TTFB, contre 55 % sur ordinateur. Sur mobile, 40 % devaient être améliorés et 17 % étaient mauvais (Web Almanac 2025, Performance).

Pourquoi le TTFB est plus élevé sur mobile

Le TTFB est plus élevé sur mobile parce que chaque étape avant le premier octet est un aller-retour, et qu’un aller-retour sur une connexion mobile prend plus de temps que sur une connexion filaire. Pour une première visite en HTTPS avec une connexion froide, la séquence est :

1. Recherche DNS, pour trouver l’adresse du serveur.
2. Poignée de main TCP : un aller-retour vers le serveur.
3. Poignée de main TLS : un aller-retour de plus avec TLS 1.3, que la RFC 8446 décrit comme la « poignée de main en 1-RTT ».
4. La requête HTTP et le premier octet de la réponse : un aller-retour plus le temps que met votre serveur.

Le réseau seul coûte donc trois allers-retours vers le serveur plus la recherche DNS, avant le travail propre du serveur. Le tableau ci-dessous est un calcul avec deux temps d’aller-retour (RTT) choisis pour l’exemple, non des mesures d’un réseau réel :

Avec le RTT le plus élevé, un serveur qui répond en 400 ms dépasse déjà le guide de 0,8 s une fois le DNS ajouté. Le serveur n’a rien fait de mal ; la mise en place de la connexion a pris plus de la moitié du budget.

Deux leviers réduisent cette surcharge. Réutilisez la connexion : un visiteur qui revient et reste connecté évite les étapes 1 à 3. Et utilisez un protocole plus récent : HTTP/3 fonctionne sur QUIC, dont la poignée de main « combine la négociation des paramètres cryptographiques et de transport » (RFC 9000, mai 2021), donc la mise en place demande moins d’allers-retours que TCP suivi de TLS. Web.dev note que les CDN servent le contenu avec des protocoles modernes comme HTTP/2 ou HTTP/3 (web.dev).

Autre cause propre au mobile : un site mobile séparé. Le conseil de Lighthouse sur les redirections indique que, pour les utilisateurs mobiles, il faut envisager le design responsive plutôt que de les rediriger vers une page mobile (Chrome for Developers). L’approche responsive est expliquée dans rendre un site web compatible mobile.

Comment mesurer le TTFB

Mesurez le TTFB deux fois : en laboratoire, pour voir où part le temps, et sur le terrain, pour voir ce que obtiennent les vrais téléphones. Les deux chiffres peuvent différer : un test en laboratoire est un chargement sur une machine, alors que la valeur terrain est le 75e percentile des visites réelles.

Dans DevTools (laboratoire), ouvrez le panneau Réseau, rechargez, sélectionnez la première requête (le document) et ouvrez l’onglet Timing. Les phases s’appellent Queueing, Stalled, DNS Lookup, Initial connection, Request sent et Waiting (TTFB), et « Waiting (TTFB) » correspond à un aller-retour plus le temps que le serveur met à préparer la réponse (référence Chrome DevTools). Si la barre Initial connection est longue et Waiting courte, le correctif concerne la mise en place de la connexion, pas l’application.

Sur la page (terrain), la bibliothèque web-vitals signale le TTFB et, dans sa version d’attribution, le découpe en ces mêmes phases. Sa documentation (README de web-vitals) les nomme waitingDuration (redirections et travail du navigateur avant la requête), cacheDuration (contrôle du cache et temps du service worker), dnsDuration, connectionDuration et requestDuration (temps réseau et traitement serveur) :

import {onTTFB} from 'web-vitals/attribution';

onTTFB(({value, rating, attribution}) => {
  // Envoyez-le à votre point de collecte analytique ; ici on affiche seulement le détail.
  console.log(rating, Math.round(value), {
    redirectsAndWaiting: attribution.waitingDuration,
    cache: attribution.cacheDuration,
    dns: attribution.dnsDuration,
    connection: attribution.connectionDuration,
    request: attribution.requestDuration,
  });
});

Par appareil (terrain, sans code), l’API Chrome UX Report accepte un formFactor de PHONE, TABLET ou DESKTOP et renvoie le 75e percentile de experimental_time_to_first_byte (une métrique expérimentale de l’API) (documentation de l’API CrUX). Les données sont une moyenne glissante sur 28 jours. C’est le moyen le plus rapide de voir si votre TTFB sur téléphone est pire que sur ordinateur. La façon de lancer l’ensemble plus large des tests de vitesse est dans le guide de test de vitesse mobile, et la façon dont Lighthouse signale le même problème est dans le guide d’audit mobile avec Lighthouse.

Côté serveur, ajoutez un en-tête Server-Timing pour voir quelle étape du backend est lente. Chrome 65, Firefox 61 et Safari 16.4 le prennent en charge (MDN browser-compat-data 8.1.7, octobre 2026) :

Server-Timing: db;dur=53, app;dur=47.2, cache;desc="miss"

Les valeurs apparaissent ensuite dans l’onglet Timing du panneau Réseau et dans navigationEntry.serverTiming de l’objet d’attribution ci-dessus.

Comment réduire le TTFB

Commencez par la phase la plus grande de votre décomposition, car chaque correctif ne supprime que sa propre phase. Ce tableau relie ce que vous voyez à ce qu’il faut changer :

Les correctifs ci-dessous suivent le guide de web.dev pour optimiser le TTFB (web.dev, mis à jour en novembre 2025).

1. Supprimez les redirections. Web.dev vous demande de retirer les redirections 301 et 302 de même origine, comme un https:// manquant ou une incohérence de barre oblique finale, et de donner l’URL finale aux annonceurs et aux newsletters. HSTS indique au navigateur d’utiliser https:// directement au lieu de demander d’abord http://.
2. Placez un CDN devant. Un CDN répond depuis un serveur de périphérie proche du visiteur, ce qui raccourcit chaque aller-retour du tableau ci-dessus. Selon web.dev, il apporte en général aussi HTTP/3, TLS 1.3 et la compression.
3. Mettez le HTML en cache. Une page identique pour tous les visiteurs peut être mise en cache avec Cache-Control et servie sans toucher à l’application. Web.dev note que des durées de cache courtes aident déjà les sites très fréquentés. Ajoutez un paramètre d’URL pour contourner le cache pendant le diagnostic.
4. Réduisez le travail du serveur. Le conseil de Lighthouse est d’optimiser la logique applicative et les requêtes de base de données, de renforcer le matériel si nécessaire, et d’utiliser un CDN pour les documents qui peuvent être mis en cache en périphérie. Utilisez Server-Timing pour trouver d’abord l’étape lente.
5. Compressez le texte. L’insight Lighthouse signale un document principal envoyé sans compression. Le navigateur annonce ce qu’il accepte dans Accept-Encoding et le serveur répond avec Content-Encoding.
6. Diffusez le HTML en flux. Web.dev conseille de garder le flux de réponse ouvert, avec un rendu serveur en streaming ou un rendu statique quand c’est possible, pour que les premiers octets partent tôt. Le vidage anticipé se mesure aussi comme responseStart, donc le TTFB peut paraître meilleur que ce que ressent la page ; regardez aussi First Contentful Paint.
7. Envoyez des 103 Early Hints. Si le serveur a besoin de temps pour construire la page, il peut envoyer d’abord une réponse 103 avec des en-têtes Link, pour que le navigateur lance un preconnect ou un preload pendant qu’il attend.

HTTP/2 103
Link: </css/app.css>; rel=preload; as=style
Link: <https://cdn.example.com>; rel=preconnect

HTTP/2 200
content-type: text/html

Early Hints fonctionne avec HTTP/2 ou plus récent dans la plupart des navigateurs, et seule la première réponse 103 est traitée (MDN, juin 2026). La prise en charge commence à Chrome 103, Firefox 120 et Safari 17. Une réponse 103 compte comme les premiers octets pour le TTFB, et Chrome a changé la marque de temps renvoyée par responseStart (sur la réponse finale dans Chrome 115, de nouveau sur les premiers octets dans Chrome 133) ; comparez donc le TTFB entre outils avec prudence (web.dev).

Si le site a un service worker, servir la structure depuis son cache raccourcit aussi le TTFB des visites répétées. Web.dev suggère stale-while-revalidate pour les ressources qui changent peu et réseau d’abord pour le HTML personnalisé.

Sites statiques et sites avec CMS

Un site statique a déjà le meilleur cas : le HTML existe avant la requête, donc le TTFB se réduit surtout à la mise en place de la connexion, et un CDN est le correctif principal. Un CMS construit la page à la demande, donc le plus grand gain vient du cache de page entière. Pour WordPress, la documentation Lighthouse cite un thème léger, un cache de page entière et moins d’extensions ; pour Drupal, le cache de page, OPcache de PHP et Redis ou Memcached ; pour Magento, Varnish (Chrome for Developers, dernière mise à jour en 2019, avant Lighthouse 13).

Une URL AMP séparée ajoute aussi une version de la page à garder cohérente avec la version canonique ; si vous en avez encore besoin, voir AMP en 2026.

Vérifiez la chaîne de redirections sur une page à la taille d’un mobile

Les redirections sont la seule cause de TTFB que l’on voit sans chronomètre : un téléphone peut être envoyé ailleurs qu’un ordinateur. Mobile View Extension recharge l’onglet avec le user agent, la taille d’écran et le ratio de pixels d’un téléphone ; vous pouvez donc vérifier sur quelle URL vous atterrissez et que la page mobile se charge comme la version réelle. Il ne mesure ni le TTFB ni aucune métrique de vitesse, et il s’exécute avec la connexion et le matériel de votre ordinateur ; pour des temps sur de vrais téléphones, utilisez les outils terrain ci-dessus.

Questions fréquentes

Quel est un bon TTFB ?

Un bon TTFB est de 0,8 seconde ou moins au 75e percentile, et plus de 1,8 seconde est mauvais, selon web.dev (novembre 2025). Ce sont des repères approximatifs, et le TTFB ne fait pas partie des Core Web Vitals.

Le TTFB est-il une Core Web Vital ?

Non. Les Core Web Vitals sont Largest Contentful Paint, Interaction to Next Paint et Cumulative Layout Shift, et web.dev précise que le TTFB n’en fait pas partie. Il compte parce qu’un TTFB élevé retarde First Contentful Paint et Largest Contentful Paint.

Pourquoi mon TTFB diffère-t-il entre Lighthouse et les données terrain ?

Lighthouse fait un chargement sur une machine avec une limitation réseau, alors que les données terrain couvrent des visites réelles, sur des réseaux et des caches réels. Faites confiance à la valeur terrain et utilisez le test de laboratoire pour trouver la phase lente.

Le TTFB affecte-t-il le SEO ?

Web.dev indique que le TTFB n’est pas une Core Web Vital, mais qu’il précède First Contentful Paint : un TTFB lent retarde donc les métriques qui suivent, surtout Largest Contentful Paint. Corrigez d’abord ces métriques et utilisez le TTFB pour comprendre pourquoi elles sont lentes.