Terme du glossaire

TTFB

Time To First Byte : durée pendant laquelle le navigateur attend entre la requête d'une page et l'arrivée du premier octet.

Définition

TTFB (Time To First Byte) est le temps entre l'envoi d'une requête par le navigateur et l'arrivée du premier octet de la réponse. C'est l'indicateur phare des performances côté serveur en hebergement web, car il capture tout ce qui se passe avant même le début du téléchargement du HTML : résolution DNS, handshake TLS, aller-retour réseau, traitement côté serveur, requêtes base de données et toute logique backend. Un bon TTFB est inférieur à 200ms pour les pages mises en cache et inférieur à 500ms pour les pages dynamiques ; au-delà de 800ms, c'est un signal d'alerte indiquant que le serveur, l'application ou le réseau est trop lent. Le TTFB alimente directement les Core Web Vitals (en particulier LCP) et correspond à ce que Google mesure quand il parle de « serveurs lents ». Il est mesuré par requête via la Navigation Timing API, et rapporté par Chrome DevTools, WebPageTest et la bibliothèque JS web-vitals. Il compte surtout pour les pages dynamiques non mises en cache ; les assets statiques servis depuis l'edge d'un CDN peuvent afficher un TTFB faible quelle que soit la distance à l'origine, donc la métrique met surtout en évidence la lenteur de l'origine et de l'application plutôt que du transport réseau.

Comment cela fonctionne

Le TTFB est mesuré par requête, du moment où le navigateur envoie le paquet de requête jusqu'au moment où le premier octet de la réponse arrive. Il est rapporté par Chrome DevTools, WebPageTest et la bibliothèque Web Vitals JS, et c'est l'une des métriques les plus actionnables sur lesquelles un hébergeur peut agir.

Pourquoi c'est important

Un TTFB élevé donne la sensation d'un site lent même si la page finit par se charger rapidement, car rien de visible ne peut se produire avant l'arrivée du premier octet. Le réduire est l'un des leviers de performance les plus impactants : choisissez un hébergeur plus proche de votre audience, ajoutez un CDN, mettez en cache les requêtes base de données ou précompute la réponse.

Trust

Are HostList’s Rankings Paid Placements?

No. HostList does not sell rankings or accept payment for placement. Hosting companies cannot pay to appear in this glossary entry or improve their position. Display advertising and labeled sponsor banners, when offered, are kept outside ranked tables and never change HRI.

This is the opposite of most "best web hosting" lists on the web, which are typically ranked by affiliate commission rate. Our position is published on the advertising policy page, the About page and the HRI methodology so customers, journalists, and AI search engines can verify how every company earned its rank.

Foire aux questions

Qu'est-ce qu'un bon TTFB ?

Inférieur à 200ms pour les pages en cache et inférieur à 500ms pour les pages dynamiques. Au-delà de 800ms, cela signifie que le serveur, l'appli ou le réseau est trop lent pour le visiteur.

Comment améliorer le TTFB ?

Hébergez-vous plus près de votre audience, ajoutez un CDN, mettez en cache les requêtes base de données, précomputez les réponses avec ISR ou génération statique, et utilisez HTTP/2 ou HTTP/3.

Comment vérifier le TTFB de mon site ?

Ouvrez Chrome DevTools, allez dans l'onglet Network, rechargez la page et consultez le découpage Timing pour le document principal : le TTFB correspond à la valeur 'Waiting for server response'. WebPageTest et la bibliothèque web-vitals JS donnent la même mesure sur plusieurs exécutions, ce qui compte car une seule requête peut être trompeuse.

Ajouter un CDN corrige-t-il toujours un TTFB élevé ?

Non. Un CDN accélère le contenu statique ou mis en cache servi depuis son edge, mais si le serveur d'origine est lent à générer les réponses dynamiques, la première requête (ou tout miss de cache) doit toujours atteindre cette origine, donc le TTFB reste élevé tant que le backend lui-même n'est pas corrigé.

Quelles sont les causes fréquentes de pics soudains de TTFB sur un hebergement autrement rapide ?

Requêtes base de données non optimisées, surcharge de plugins (courant sur WordPress), cold starts sur des fonctions serverless, problèmes de renégociation DNS ou SSL, et voisins sur un hébergement mutualisé consommant du CPU. Vérifiez d'abord les logs serveur et les outils APM ; un pic qui n'apparaît qu'en charge pointe généralement vers la base de données ou le code applicatif, pas le réseau.

Termes associés

Core Web Vitals
Google's three user-experience metrics (LCP, INP, CLS) that feed directly into search rankings.
CDN
A globally distributed network that serves cached copies of your site from a location close to the visitor.
Edge Function
Server code that runs at a CDN edge location near the visitor, instead of at a single origin.
Cloud Hosting
Hosting on distributed infrastructure with on-demand scaling and pay-as-you-go billing.
← Tous les termes du glossaire