Mis à jour le 15 juillet 2026 · Relu et vérifié par Damien Hernandez
TTFB (Time to First Byte) : definition, role et bonnes pratiques SEO
Le Time to First Byte (TTFB) mesure le temps de reponse initial d’un serveur. Le TTFB, aussi nomme temps de reponse serveur, court du depart de la navigation jusqu’au premier octet recu. En SEO, Google recommande via web.dev un bon TTFB sous 800 ms au 75e centile.
A retenir
- Le seuil « bon » est fixe a 800 ms ou moins au 75e centile, selon web.dev (nov. 2025).
- Le TTFB n’est pas un Core Web Vital : c’est une metrique diagnostique, selon web.dev.
- Seuls 44 % des sites mobiles atteignent un bon TTFB, selon le Web Almanac 2025.
Comment fonctionne le TTFB ?
Le TTFB additionne cinq phases reseau avant le premier octet du serveur. La chaine comprend le temps de redirection, la resolution DNS, la connexion TCP, la negociation TLS, puis le traitement de la requete cote serveur. Le navigateur mesure ce delai via la Navigation Timing API, entre startTime et responseStart. Un site rendu cote serveur peut afficher un TTFB plus eleve mais un meilleur LCP qu’une application monopage. Selon web.dev, les seuils TTFB restent un repere indicatif, a ponderer selon le mode de livraison du contenu.
Pourquoi le TTFB est important pour le SEO ?
Le TTFB precede et plafonne le LCP, metrique de classement de Google. Un TTFB de 1,5 s consomme deja plus de la moitie du budget de 2,5 s d’un bon LCP, selon web.dev. Le TTFB n’entre pas directement dans les Core Web Vitals, mais un serveur lent bride toute la suite du chargement. Le Web Almanac 2025 de HTTP Archive releve que seuls 44 % des sites mobiles atteignent un bon TTFB. Reduire ce delai reste souvent le levier le plus rapide pour repasser le LCP en zone verte.
| Seuil cite | Origine | Statut en 2026 |
|---|---|---|
| 200 ms | Ancienne doc PageSpeed (API v4) | Guidage retire, obsolete depuis 2019 |
| 600 ms | Alerte PageSpeed « temps de reponse serveur » | Seuil d’alerte de l’outil, pas le seuil officiel |
| 800 ms | web.dev, mis a jour nov. 2025 | Reference actuelle, au 75e centile |
Un TTFB serveur qui plombe votre LCP ? Demandez un audit technique
Comment reduire le TTFB ?
Reduire le TTFB passe d’abord par le cache serveur et un hebergement adapte. Activez un cache de page, un cache objet Redis, puis servez le HTML depuis un CDN en edge. Supprimez les chaines de redirection : chaque saut ajoute un aller-retour reseau compte dans le TTFB. web.dev conseille de traiter le TTFB en priorite, car il precede le FCP et le LCP, avec un objectif de 800 ms au 75e centile.
Le TTFB est-il un facteur de classement Google ?
Le TTFB n’est pas un facteur de classement direct, car il ne fait pas partie des Core Web Vitals. Google le classe comme metrique diagnostique. Son impact reste fort et indirect : un TTFB eleve retarde le LCP, qui entre dans le signal Page Experience. Le seuil bon du LCP est fixe a 2,5 s, selon web.dev, et un serveur lent le rend inatteignable.
Exemple concret de mesure du TTFB
Une commande curl mesure le TTFB reel d’une URL en isolant le temps jusqu’au premier octet. Comparez la valeur avec cache actif puis cache vide pour localiser un goulot serveur ou base de donnees.
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://exemple.fr/Erreur fréquente observée en audit
Erreur observée. Un TTFB élevé est souvent attribué immédiatement à l’hébergement. Pourtant, la mesure inclut aussi les redirections, la résolution DNS, la connexion TCP, la négociation TLS et le traitement serveur. L’audit doit décomposer ces étapes, puis comparer les réponses avec et sans cache avant d’identifier l’origine du délai.
Sources
- web.dev – Time to First Byte (TTFB) · nov. 2025
- web.dev – Optimize Time to First Byte · nov. 2025
- HTTP Archive – Web Almanac 2025, chapitre Performance · 2025
Termes lies
Damien Hernandez · Consultant SEO senior, 15 ans d’experience (Accor, Louvre Hotels, Infopro Digital). Specialiste SEO technique et GEO (optimisation pour les moteurs generatifs).