TL;DRLe TTFB est le temps que met votre serveur à commencer à répondre. Tant qu'il n'est pas écoulé, rien ne s'affiche. Voici comment le mesurer correctement, ce que nous avons relevé sur notre propre site et les causes à traiter en priorité.
Qu'est-ce que le TTFB ?#
Le TTFB, pour Time To First Byte, est le temps qui s'écoule entre le moment où le navigateur demande une page et le moment où il reçoit le premier octet de la réponse. Pendant ce délai, l'écran du visiteur reste vide : rien ne peut s'afficher tant que le serveur n'a pas commencé à répondre.
Ce temps additionne plusieurs étapes : les éventuelles redirections, la résolution DNS, l'ouverture de la connexion et la négociation du chiffrement, puis le travail du serveur pour fabriquer la page, et enfin le trajet retour du premier octet.
Quel est un bon TTFB ?#
| TTFB | Appréciation | Ce que cela signifie |
|---|---|---|
| Jusqu'à 0,8 s | Bon | Le serveur ne freine pas l'affichage. |
| De 0,8 à 1,8 s | À améliorer | Le retard se reporte sur tous les autres indicateurs de vitesse. |
| Au-delà de 1,8 s | Mauvais | La page ne peut pas être perçue comme rapide, quoi que l'on optimise ensuite. |
Ces seuils sont ceux que recommande Google sur web.dev, mesurés sur les visites réelles. L'outil Lighthouse est plus strict pour la seule réponse du serveur : son audit « Réduire le temps de réponse initial du serveur » échoue au-delà de 600 ms.
Le TTFB ne fait pas partie des Core Web Vitals, les trois indicateurs que Google suit en priorité. Il les conditionne pourtant directement : le plus grand élément visible (LCP) ne peut pas s'afficher avant que le premier octet soit arrivé. Un TTFB d'une seconde et demie rend un bon LCP presque impossible à atteindre.
Mesurer le TTFB#
Dans le navigateur#
Ouvrez les outils de développement (touche F12), onglet Réseau, rechargez la page et cliquez sur la première ligne. Dans l'onglet « Durée », la ligne « En attente de la réponse du serveur » correspond à la partie serveur du TTFB.
En ligne de commande#
La commande curl détaille chaque étape, ce qui permet de savoir où le temps est perdu :
curl -s -o /dev/null -w 'DNS %{time_namelookup}s | connexion %{time_connect}s | TLS %{time_appconnect}s | premier octet %{time_starttransfer}s\n' https://exemple.fr/La valeur time_starttransfer est le TTFB. Si elle est élevée alors que les trois premières sont faibles, le temps est perdu dans l'application, pas sur le réseau.
Sur les visites réelles#
PageSpeed Insights affiche, quand le site reçoit assez de trafic, le TTFB constaté chez les utilisateurs de Chrome sur les 28 derniers jours. C'est la mesure qui compte : elle intègre les connexions mobiles lentes et les visiteurs éloignés du serveur, qu'un test ponctuel depuis votre bureau ne reflète pas.
Bon à savoir. Une mesure isolée ne vaut rien. Le TTFB varie d'une requête à l'autre selon la charge du serveur et l'état des caches. Lancez toujours une série (dix requêtes au minimum) et retenez la médiane plutôt que la moyenne, qu'une seule requête lente suffit à fausser.
Notre mesure : où part le temps sur notre propre site#
Nous avons mesuré le TTFB de websource.fr le 13 octobre 2026 avec la commande ci-dessus : dix requêtes par adresse, médiane retenue. Le site tourne sous Symfony (PHP 8.5, Apache 2.4, cache OPcache actif), derrière le proxy Cloudflare. Les requêtes partent du serveur lui-même, ce qui neutralise le temps de trajet réseau et isole le travail du serveur.
| Ressource demandée | Directement au serveur | À travers Cloudflare |
|---|---|---|
| Fichier statique (robots.txt) | 7 ms | 34 ms |
| Plan du site (sitemap.xml) | 76 ms | non mesuré |
| Page d'accueil | 124 ms | 199 ms |
| Article de blog | 132 ms | 192 ms |
| Liste des articles du blog | 148 ms | 207 ms |
Trois constats se dégagent de ces chiffres.
- Le serveur web lui-même est négligeable. Un fichier statique part en 7 ms, négociation du chiffrement comprise. Une page générée par l'application demande 124 à 148 ms. Sur une page dynamique, environ 95 % du TTFB est donc du temps d'exécution du code et de la base de données. C'est là qu'il faut chercher, pas dans les réglages du serveur web.
- Plus une page interroge la base, plus elle est lente. La liste des articles, qui exige le plus de requêtes, est la plus longue à produire.
- Un proxy n'accélère pas une page qu'il ne met pas en cache. Nos pages HTML ne sont pas mises en cache par Cloudflare (la réponse porte l'en-tête
cf-cache-status: DYNAMIC). Chaque requête fait donc un aller-retour supplémentaire, ce qui ajoute 60 à 75 ms dans notre mesure.
Ce dernier point mérite une nuance : nos requêtes partent du serveur, situation la moins favorable au proxy. Pour un visiteur éloigné, la connexion se termine sur un point de présence proche de lui, ce qui compense une partie de ce surcoût. Il reste que l'idée reçue « un CDN réduit le TTFB » n'est vraie que si le CDN sert lui-même la page depuis son cache.
Réduire le TTFB : les causes et leurs remèdes#
| Cause | Comment la reconnaître | Remède |
|---|---|---|
| Aucun cache de page | Chaque page est recalculée à chaque visite ; le TTFB est le même pour un visiteur et pour mille. | Cache de page complet côté application ou côté serveur pour les pages publiques. |
| Requêtes SQL lentes | Le TTFB grimpe sur les listes et les recherches, pas sur les pages simples. | Journal des requêtes lentes, index manquants, requêtes répétées en boucle à regrouper. |
| Cache de code PHP inactif | Toutes les pages sont lentes, y compris les plus simples. | Activer et dimensionner OPcache. |
| Serveur saturé | TTFB correct la nuit, dégradé aux heures de pointe. | Ajuster le nombre de processus PHP, surveiller mémoire et processeur, changer de gamme si nécessaire. |
| Redirections en chaîne | Le premier octet « utile » arrive après deux ou trois réponses 301. | Une seule redirection, directement vers l'adresse finale. |
| Serveur éloigné des visiteurs | Temps de connexion et TLS élevés dans la mesure curl. | Héberger près de son public ; cache du CDN pour ce qui peut l'être. |
| Extensions ou modules lourds | Le TTFB a augmenté après une installation. | Désactiver un à un pour identifier le responsable. |
Par où commencer#
- Mesurez une page simple et une page lourde. Si les deux sont lentes, le problème est général (cache de code, serveur saturé). Si seule la lourde l'est, cherchez du côté de la base de données.
- Comparez un fichier statique et une page. Comme dans notre mesure, l'écart donne la part du temps imputable à l'application.
- Comptez les redirections.
curl -sIL http://exemple.fr/liste toutes les réponses intermédiaires. - Mettez en cache ce qui est identique pour tous. C'est le levier le plus puissant : une page servie depuis un cache se rapproche du temps d'un fichier statique.
- Mesurez à nouveau, dans les mêmes conditions. Sans mesure avant et après, impossible de savoir si une modification a servi.
Un TTFB qui dérive jusqu'à l'absence de réponse finit en erreur 504 Gateway Timeout : les causes sont les mêmes, poussées à l'extrême.
L'hébergement compte, mais pas seul#
Un hébergement sous-dimensionné ou surchargé plafonne le TTFB quoi que l'on fasse dans le code. À l'inverse, le meilleur serveur ne compensera pas une page qui lance des centaines de requêtes SQL. Les deux se travaillent ensemble. Pour savoir si le serveur est vraiment en cause sur votre site, suivez notre diagnostic d'un site lent en 5 étapes.
Websource héberge un grand nombre de sites et nous accompagnons nos clients dès la commande : sur nos offres d'hébergement web, nous indiquons quoi régler chez le gestionnaire du nom de domaine, et si le site existe déjà ailleurs, sa migration est offerte avec les offres Premium et Advanced, et réalisée sur devis avec l'offre Standard. Pour les serveurs dédiés, notre article sur l'infogérance serveur détaille ce que couvre la surveillance des performances.
Questions fréquentes#
Que veut dire TTFB ?#
Time To First Byte, soit « temps jusqu'au premier octet ». C'est le délai entre la demande d'une page par le navigateur et la réception du premier octet de la réponse du serveur.
Quel est un bon TTFB ?#
Google recommande 0,8 seconde au maximum, mesuré sur les visites réelles. Entre 0,8 et 1,8 seconde, il est à améliorer ; au-delà, il est considéré comme mauvais. L'audit Lighthouse du temps de réponse du serveur échoue dès 600 ms.
Le TTFB est-il un critère de référencement ?#
Il ne fait pas partie des Core Web Vitals, mais il les conditionne : le plus grand élément visible de la page (LCP) ne peut pas s'afficher avant l'arrivée du premier octet. Un TTFB élevé dégrade donc mécaniquement les indicateurs suivis par Google.
Un CDN réduit-il le TTFB ?#
Seulement s'il sert la page depuis son cache, ou s'il rapproche nettement la connexion d'un visiteur éloigné. Pour une page HTML non mise en cache, il ajoute un intermédiaire : nous avons mesuré 60 à 75 ms supplémentaires sur notre site.
Comment mesurer le TTFB sans outil payant ?#
Avec les outils de développement du navigateur (onglet Réseau), avec la commande curl et sa variable time_starttransfer, ou avec PageSpeed Insights, qui affiche le TTFB constaté sur les visites réelles quand le trafic est suffisant.
Article publié le 19/10/2026 sous la signature de Jonathan Gutierrez, rédigé à partir des sources citées ci-dessus, puis relu avant publication. Une information vous semble inexacte ou datée ? Signalez-le nous, nous corrigeons.
