Premier octet : le temps de réflexion du serveur
Ou : le serveur a reçu votre question ; reste à savoir combien de temps il réfléchit.
La réponse courte : le TTFB (Time To First Byte) est le temps qui sépare la demande d’une page de l’arrivée de son premier octet dans le navigateur. Il additionne une éventuelle redirection, la résolution DNS, la connexion, la négociation TLS et le temps que le serveur met à préparer sa réponse. L’article de web.dev consacré au TTFB le juge bon à 0,8 seconde ou moins, et mauvais au-delà de 1,8 seconde. C’est le premier chiffre à regarder pour juger les performances de l’hébergeur, parce que c’est sur lui que l’hébergeur a le plus de prise.
Le seuil de 0,8 seconde est une limite haute, pas un objectif. web.dev rappelle que le TTFB n’est pas une Core Web Vital : il compte parce qu’il retarde tout le reste, à commencer par l’affichage du plus grand élément de la page. Mon repère, pour un site servi à des visiteurs du même pays, est de rester sous 400 millisecondes ; une page dynamique, recalculée à chaque visite, s’en approche moins facilement qu’un fichier statique ou une page en cache, c’est-à-dire gardée toute prête.
Pour qui : un site vitrine ou un blog dont le temps de réponse dépasse la demi-seconde chez son hébergeur actuel, et qui veut repartir sur une offre mesurable.
À partir de : 5,75 € par mois hors taxes pour l’hébergement web Infomaniak, facturés à l’année (relevé du 12 novembre 2026).
Pour démarrer : ouvrir l’essai gratuit de 30 jours, y déposer une page témoin et mesurer son TTFB avec curl avant de déplacer le reste du site.
Bon TTFB : seuils, décomposition et mesure du temps de réponse serveur
PageSpeed Insights classe le TTFB réel de vos visiteurs, celui que collecte le rapport CrUX de Chrome, en trois catégories, au 75e centile des visites des 28 derniers jours :
| TTFB au 75e centile | Verdict de Google | Lecture pratique |
|---|---|---|
| 0,8 s ou moins | bon | le serveur ne freine pas l’affichage |
| de 0,8 à 1,8 s | à améliorer | serveur chargé, cache absent ou visiteurs lointains |
| plus de 1,8 s | mauvais | le LCP a peu de chances de passer sous 2,5 s |
Seuils relevés le 12 novembre 2026. Une mesure isolée faite depuis votre bureau ne remplace pas ces données de terrain, mais elle dit autre chose : où passe le temps. Pour cela, la commande curl suffit. Ses variables de sortie, décrites dans le manuel de curl, comptent chacune le temps écoulé depuis le début de la requête :
| |
| Variable | Ce qu’elle marque | Ce qu’elle trahit |
|---|---|---|
time_namelookup | fin de la résolution DNS | serveurs DNS lents, premier appel sans cache |
time_connect | connexion TCP établie | la distance : un aller-retour réseau |
time_appconnect | négociation TLS terminée | la distance, encore, et la configuration TLS |
time_starttransfer | premier octet reçu : le TTFB | le travail du serveur : PHP, base de données, cache |
time_total | transfert terminé | le poids de la page et le débit |
La soustraction est l’outil de diagnostic. time_starttransfer moins time_appconnect donne, à peu de chose près, le temps de réflexion du serveur. time_appconnect lui-même mesure surtout la géographie. Si le premier chiffre domine, le problème est chez l’hébergeur ou dans le code ; si c’est le second, il est dans la distance.
Pour départager le serveur et le site, Infomaniak propose dans sa fiche sur le temps de réponse un test simple : déposer un fichier statique, index2.html, à côté de la page d’accueil, et comparer. Si le fichier statique répond vite et la page d’accueil lentement, la lenteur vient du site, pas de la machine. Le test vaut chez n’importe quel hébergeur.
Trois précautions rendent la mesure honnête :
- Répéter : vingt requêtes espacées, puis la médiane et le 90e centile, jamais le meilleur chiffre.
- Mesurer d’où sont les visiteurs : un serveur parisien mesuré depuis Montréal ajoute plus de 80 millisecondes à chaque aller-retour, d’après les relevés publiés par WonderNetwork le 12 novembre 2026.
- Distinguer la première visite : la première requête paie la résolution DNS et parfois le réveil d’un processus PHP endormi ; les suivantes, non.
La distance compte avant le code
Une nouvelle connexion HTTPS demande au moins trois allers-retours avant le premier octet : la connexion TCP, la négociation TLS 1.3, puis la requête elle-même. À 15 millisecondes l’aller-retour, c’est négligeable ; à 85, c’est un quart de seconde avant que le serveur ne commence à travailler. Le choix du centre de données se traite donc avant l’optimisation du code, avec la localisation du serveur et sa latence.
Ne pas recalculer ce qui n’a pas changé
La plus grande part du temps de réflexion d’un site PHP se passe à compiler les scripts et à interroger la base de données pour produire une page identique à celle d’il y a une minute. OPcache et un cache de page suppriment ce travail ; les en-têtes à lire pour savoir quel étage répond sont expliqués dans la mise en cache côté serveur.
Chronométrer avant de signer
Un TTFB se mesure mieux sur l’offre qu’on envisage que sur la page commerciale de l’hébergeur. Les délais d’essai ou de remboursement de 30 jours laissent le temps de comparer deux candidats avec la même page témoin, selon un protocole de test pendant l’essai.