Le time to first byte, ou TTFB, mesure le temps entre l’envoi d’une requête par le navigateur et la réception du premier octet de réponse. En clair : avant même de parler d’images, de JavaScript ou de rendu visuel, le navigateur attend un premier signal du serveur. Si ce délai avant le premier octet est élevé, la page part avec du retard. Dans les Core Web Vitals, il influence surtout le départ de l’expérience utilisateur.
Qu’est-ce que le Time to First Byte ?
Le Time to First Byte, souvent abrégé en TTFB, se traduit par temps avant le premier octet. C’est une métrique de performance web qui regarde le démarrage de la réponse serveur, pas le chargement complet de la page.
Bon, c’est une nuance importante. Une page peut avoir un TTFB correct et rester lente si son CSS bloque le rendu, si ses images sont trop lourdes ou si son JavaScript monopolise le navigateur. À l’inverse, un mauvais TTFB plombe presque toujours le départ, car rien de visible ne peut vraiment avancer tant que le document HTML ne commence pas à arriver.
Pour une agence web éco-responsable comme GreenCodeLab, le TTFB sert surtout de signal de diagnostic. Il aide à repérer une architecture trop lourde, un cache absent, un CMS saturé ou un hébergement mal dimensionné.
Que mesure exactement le TTFB ?
Le TTFB n’est pas uniquement le « temps de calcul du serveur ». Selon l’outil et le contexte, il peut englober plusieurs étapes avant le premier octet :
- la résolution DNS ;
- l’ouverture de la connexion TCP ;
- la négociation TLS sur HTTPS ;
- l’envoi de la requête HTTP ;
- le traitement côté serveur, CMS, base de données, rendu SSR ou API ;
- le retour du premier octet vers le navigateur.
Voilà pourquoi deux tests lancés depuis Paris, Montréal ou Singapour ne donnent pas le même résultat. La localisation de l’utilisateur, celle du serveur, la qualité du réseau et le CDN changent la mesure.
Petite subtilité moderne : avec les réponses HTTP 103 Early Hints, certains outils peuvent compter une réponse anticipée comme premier octet. MDN recommande de regarder finalResponseHeadersStart quand on veut isoler le début de la réponse finale. Ce n’est pas un détail glamour, mais ça évite de comparer des chiffres qui ne mesurent pas exactement la même chose.
Quel est un bon TTFB ?
Il n’existe pas un seuil universel. Franchement, les tableaux de scores sortis de leur contexte créent souvent de mauvaises priorités. Mais quelques repères aident à décider si le sujet mérite une vraie enquête.
| Repère | Lecture pratique | À interpréter selon |
|---|---|---|
| < 200 ms | Excellent et ambitieux pour beaucoup de pages serveur | Type de page, cache, distance utilisateur |
| 200 à 600 ms | Correct, mais à surveiller sur les pages clés | Trafic, CMS, panier e-commerce, personnalisation |
| > 600 ms | Alerte fréquente dans Lighthouse/PageSpeed Insights | Test ponctuel, localisation, état du serveur |
| ≤ 0,8 s au 75e percentile | Repère satisfaisant cité par web.dev | Données terrain, population réelle d’utilisateurs |
| > 1,8 s | Mauvais signal pour le démarrage du chargement | Pages très dynamiques, marchés éloignés, absence de CDN |
En pratique, je préfère regarder la tendance sur plusieurs mesures plutôt qu’un seul test Lighthouse à 9 h 12. Si le TTFB dépasse régulièrement 600 ms sur les pages SEO ou transactionnelles, il faut creuser. Si les données terrain restent sous 0,8 s au 75e percentile, on peut parfois prioriser autre chose : LCP, poids de page, scripts tiers, images.
Pourquoi le TTFB compte pour la performance web et le SEO ?
Un TTFB lent retarde le démarrage du rendu. Le navigateur reçoit le HTML plus tard, donc le First Contentful Paint et le Largest Contentful Paint (LCP) peuvent partir avec un handicap. Ce n’est pas automatique, mais c’est fréquent.
Côté SEO, il faut rester sérieux. Un TTFB bas ne propulse pas magiquement une page en première position. Google ne récompense pas un serveur rapide si le contenu est faible, mal structuré ou inutile. En revanche, sur un gros site, un temps de réponse serveur élevé peut fatiguer le crawl, ralentir l’exploration de pages profondes et compliquer l’indexation de volumes importants.
Pour un site e-commerce ou B2B, l’effet est concret : l’utilisateur attend plus longtemps avant de voir quelque chose. Et l’attente s’ajoute aux autres irritants : pop-up, scripts marketing, images héros énormes, formulaire lent.
TTFB, Core Web Vitals et sobriété numérique : ne pas optimiser à l’aveugle
Le TTFB n’est pas un Core Web Vital central au même titre que LCP, INP ou CLS. Il reste une métrique de support, très utile pour comprendre pourquoi une page démarre lentement.
Un TTFB bas ne suffit pas
Là où le sujet devient intéressant pour l’éco-conception web, c’est qu’un mauvais TTFB révèle souvent du gaspillage : requêtes SQL inutiles, plugins qui chargent trop, rendu dynamique alors qu’une page pourrait être cacheable, appels API bloquants pour afficher trois informations secondaires.
Optimiser le TTFB ne veut donc pas dire courir après un score Lighthouse flatteur. L’objectif est plus sain : une architecture simple, cacheable, maintenable, avec moins de calcul serveur inutile. La sobriété numérique commence aussi là, dans les traitements qu’on évite avant même d’envoyer le premier octet.
Quelles sont les causes d’un TTFB élevé ?
Les causes reviennent souvent. Pas toujours dans le même ordre, hélas.
- Un hébergement sous-dimensionné, mutualisé saturé ou mal localisé par rapport aux utilisateurs.
- Un cache serveur absent, désactivé sur les pages clés ou invalidé trop souvent.
- Des requêtes base de données lentes : filtres produits, recherche interne, métadonnées WordPress, tables gonflées.
- Un thème ou des plugins CMS trop lourds, surtout quand ils déclenchent du traitement à chaque visite.
- Des API tierces appelées côté serveur avant de renvoyer le HTML.
- Une latence réseau élevée, liée à la distance, au DNS, à TLS ou à l’absence de CDN.
- Des pics de trafic sans marge CPU/RAM suffisante.
Sur WordPress, le trio classique est brutal : trop de plugins, pas de full page cache, base de données jamais nettoyée.
Comment mesurer le Time to First Byte ?
Pour un premier diagnostic, PageSpeed Insights et Lighthouse donnent une alerte rapide sur le temps de réponse serveur. Ce n’est pas suffisant pour conclure, mais c’est utile pour repérer une anomalie.
Ensuite, Chrome DevTools permet de regarder la requête du document principal dans l’onglet Network. La partie « Waiting for server response » donne une lecture proche du TTFB côté navigateur. WebPageTest va plus loin avec un waterfall lisible, plusieurs localisations de test et des répétitions.
Quand le projet le justifie, les données terrain sont préférables : CrUX, web-vitals, monitoring applicatif, logs serveur, APM. Un test lab isolé peut mentir par hasard.
La bonne méthode : mesurer plusieurs fois, depuis plusieurs zones, puis comparer pages cacheables, pages dynamiques et pages business critiques.
Comment améliorer son TTFB ?
Je commencerais par le cache. Pas par une refonte complète. Pas par un CDN vendu comme solution miracle. Le cache HTML ou full page cache règle souvent une grande partie du problème sur les pages publiques.
- Activer un cache page ou cache serveur, puis vérifier l’invalidation. Un cache qui sert une ancienne page produit, c’est une autre catastrophe.
- Optimiser les requêtes SQL et supprimer les traitements backend inutiles. Les pages qui calculent tout à chaque visite coûtent cher.
- Choisir un hébergement adapté au trafic, à la pile technique et aux pays ciblés. Le moins cher finit souvent par coûter du temps humain.
- Utiliser un CDN quand la distance réseau pèse vraiment. Il réduit la latence, mais ne corrige pas un backend lent si chaque page reste dynamique.
- Réduire les appels API bloquants. Si une donnée peut être préchargée, mise en cache ou chargée après le rendu initial, faites-le.
- Compresser avec mesure. Gzip ou Brotli sont utiles, mais une compression trop coûteuse sur des réponses dynamiques peut déplacer le problème côté CPU.
- Sur WordPress, auditer thème, plugins, object cache, transients, cron interne et full page cache. C’est rarement élégant, mais c’est efficace.
Checklist diagnostic
Le bon arbitrage dépend du type de page. Une fiche produit personnalisée, une page de compte client et une page lexique cacheable n’ont pas les mêmes contraintes. Bref, le TTFB se traite avec méthode, pas avec une extension installée au hasard.
Le TTFB est-il un Core Web Vital ?
Non. Le TTFB n’est pas un Core Web Vital principal, mais il influence souvent le démarrage des métriques visibles comme FCP et LCP.
Quelle différence entre TTFB et LCP ?
Le TTFB mesure l’arrivée du premier octet de réponse. Le LCP mesure l’affichage du plus grand élément visible dans la fenêtre. Le premier concerne surtout le démarrage serveur et réseau, le second l’expérience de rendu.
Comment voir le TTFB dans Chrome DevTools ?
Ouvrez l’onglet Network, rechargez la page, cliquez sur la requête du document HTML, puis regardez le timing associé à l’attente de réponse serveur.
Un CDN réduit-il toujours le TTFB ?
Non. Il aide quand la latence réseau ou la distance pèsent. Si le serveur doit recalculer une page dynamique à chaque requête, le CDN ne fera pas de miracle sans stratégie de cache.
À retenir sur le Time to First Byte
Le Time to First Byte est un bon signal de réactivité serveur. Il dit si le navigateur reçoit vite un premier octet, pas si la page entière est agréable à utiliser. C’est précisément pour ça qu’il faut le lire avec les Core Web Vitals, le poids de page, les scripts et les données terrain.
Un TTFB élevé mérite une enquête sur le cache, l’hébergement, la base de données, les API et le CMS. Pour continuer le diagnostic, le plus logique est de replacer cette métrique dans une lecture complète des Core Web Vitals et de l’éco-conception web.