TTFB
Le Time to First Byte (TTFB) mesure le temps que met le navigateur à recevoir le premier octet du serveur après une requête. Il reflète la rapidité de réponse du serveur lui-même, le point de départ de toutes les autres mesures de vitesse (LCP, FCP, chargement de la page).
Le Time to First Byte (TTFB) mesure le temps que met le navigateur à recevoir le premier octet du serveur après une requête. Il reflète la rapidité de réponse du serveur lui-même, le point de départ de toutes les autres mesures de vitesse (LCP, FCP, chargement de la page).
Pourquoi c'est important
Le TTFB ne fait pas partie des Core Web Vitals officiels, mais le LCP ne peut pas être bon si le TTFB ne l'est pas d'abord. Le seuil recommandé par Web.dev pour 2026 est de ≤ 800 ms ; tout ce qui dépasse 1,8 s entraîne un taux de rebond et une perte de classement mesurables. Une analyse de Cloudflare fait état d'une hausse de conversion d'environ 12 % sur les sites ayant réduit leur TTFB de 500 ms. Le TTFB est facile à mesurer, réagit instantanément aux optimisations du CDN, de l'hébergement et du serveur, et figure en haut de toute liste de priorités en SEO technique.
Composantes
Le TTFB est la somme de plusieurs étapes réseau et serveur :
- Résolution DNS : conversion du domaine en adresse IP
- Connexion TCP : poignée de main en trois temps
- Négociation TLS : poignée de main de chiffrement HTTPS
- Envoi de la requête : acheminement de la requête vers le serveur
- Traitement serveur : génération de la réponse par l'application (requêtes BDD, rendu)
- Premier octet reçu : arrivée du premier octet dans le navigateur
Un ralentissement à n'importe quelle étape augmente le TTFB.
Seuils
| Évaluation | TTFB |
|---|---|
| Bon | ≤ 800 ms |
| À améliorer | 800 ms à 1,8 s |
| Médiocre | > 1,8 s |
Évalué au 75e centile (p75) des données d'utilisateurs réels issues du Chrome User Experience Report.
Comment l'améliorer
Utilisez un CDN : les serveurs en périphérie gèrent le DNS, le TCP, le TLS et le transfert des requêtes au plus près de l'utilisateur, le gain le plus important à lui seul.
Activez HTTP/2 et HTTP/3 : la réutilisation des connexions et le multiplexage réduisent le coût des poignées de main. Généralement actifs par défaut sur Cloudflare, Fastly et autres CDN similaires.
Mise en cache côté serveur : mettez en cache les pages dynamiques dans Redis ou Varnish pour retirer plusieurs centaines de millisecondes au traitement serveur.
Optimisez les requêtes BDD : les requêtes lentes, les index manquants et les problèmes N+1 dominent le temps de traitement serveur.
Génération de site statique (SSG) : des frameworks comme Next.js et Astro précompilent les pages en HTML, de sorte que le serveur se contente de renvoyer un fichier statique. Le TTFB chute considérablement.
Choisissez la bonne région serveur : hébergez près de votre principale base d'utilisateurs.
Réduisez les cookies et les en-têtes : des cookies surchargés et des en-têtes de suivi gonflent la taille des requêtes et des réponses.
Supprimez les chaînes de redirection : chaque redirection augmente le TTFB. Gardez les redirections directes.
Outils de mesure
- Chrome DevTools → Network → Timing : décomposition du TTFB par requête
- WebPageTest : TTFB par région et par appareil
- PageSpeed Insights : données de terrain basées sur CrUX
- Search Console → Core Web Vitals : tendances du TTFB des utilisateurs réels
Sources: