TTFB, temps de réponse et latence : ce que chacun mesure

Ce que signifie chaque terme

La latence réseau, souvent rapportée comme temps aller-retour, est le temps qu'un paquet passe à voyager vers le serveur et à en revenir, sans aucun traitement applicatif entre les deux. Elle est déterminée par la distance physique, le nombre de sauts et la qualité de la route. Rien de ce que vous faites dans votre code ne la change.

Le temps jusqu'au premier octet (TTFB) est mesuré depuis le moment où le client lance la requête jusqu'à ce que le premier octet de la réponse l'atteigne. Cette tranche contient la résolution DNS, la connexion TCP, la poignée de main TLS, le temps que la requête passe en transit, tout ce que le serveur fait pour produire une réponse, et le trajet de retour. Le TTFB est donc toujours plus grand qu'un seul aller-retour, généralement de plusieurs fois.

Le temps de réponse est le plus flou des trois. La plupart des outils de surveillance l'utilisent pour désigner le temps total nécessaire pour compléter la requête, du premier paquet au dernier octet du corps. Certains outils l'utilisent comme synonyme du TTFB. Avant de comparer deux chiffres tous deux étiquetés « temps de réponse », vérifiez sur quel instant chaque outil a arrêté son chronomètre.

Comment chacun est mesuré

La latence provient d'un écho ICMP, ce que ping envoie, ou du chronométrage de la poignée de main TCP quand ICMP est bloqué. Le TTFB et le temps total proviennent du client HTTP lui-même. Un seul appel curl affiche toutes ces bornes :

curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://example.com/

Chaque valeur est cumulative depuis le début de la requête, donc vous les lisez comme des bornes plutôt que comme des durées. Soustrayez la valeur précédente pour obtenir la longueur d'une étape.

Quel chiffre votre outil vous montre-t-il

Chaque outil rapporte une tranche différente de la même requête, ce qui explique en général pourquoi deux mesures d'un même site ne concordent pas :

• ping ne rapporte que la latence aller-retour, sans aucun traitement serveur inclus
• curl -w rapporte chaque borne listée ci-dessus, ce qui en fait la référence quand les chiffres divergent
• Les outils de développement du navigateur affichent le TTFB comme l'étape d'attente d'une requête, séparée de l'étape de téléchargement en dessous
• Lighthouse et PageSpeed rapportent le temps de réponse serveur, qui est le TTFB pour la requête du document
• Les moniteurs de disponibilité rapportent un temps de réponse dont la définition varie selon le produit, et qui inclut l'établissement de la connexion depuis l'endroit où la vérification s'est exécutée
• Le suivi d'utilisateurs réels rapporte un TTFB de terrain, agrégé sur de vrais visiteurs et de vrais réseaux

À quoi ressemble un bon chiffre

La latence est bornée par la géographie. Moins de 30 ms est normal à l'intérieur d'une même zone métropolitaine, 50 à 100 ms sur un continent, et 150 à 250 ms entre continents. Une route dont la mesure dépasse nettement la distance attendue suggère un mauvais chemin plutôt qu'un serveur lent.

Pour le TTFB, web.dev considère 800 ms ou moins comme bon et tout ce qui dépasse 1,8 seconde comme médiocre, tandis que l'audit de temps de réponse serveur de Lighthouse commence à échouer au-delà de 600 ms. Visez moins de 600 ms pour la requête du document et considérez 200 ms comme la cible pour tout ce qui est mis en cache ou servi statiquement.

Le temps de réponse total dépend de la taille de ce que vous envoyez, donc il n'existe pas de chiffre universel. Mesurez votre propre référence un jour normal et traitez l'écart par rapport à cette référence comme le signal, pas le chiffre absolu.

Lire les écarts

Les chiffres individuels comptent moins que la distance entre eux, car chaque écart pointe vers un sous-système différent :

• Le TTFB moins la latence aller-retour correspond à peu près au temps que le serveur a passé à réfléchir. Si c'est la part la plus grande, le problème vient du code applicatif, d'une requête lente ou d'un cache froid
• La connexion moins la résolution DNS représente un aller-retour pour la poignée de main TCP. Si c'est bien plus grand que votre latence mesurée, le chemin réseau est congestionné ou mal routé
• Le TLS moins la connexion est le coût de la poignée de main, typiquement un ou deux allers-retours supplémentaires, et une valeur élevée pointe vers un problème de chaîne de certificats ou de reprise de session
• Le total moins le TTFB est le temps de transfert. Si c'est ce qui domine, la réponse est trop volumineuse ou la connexion trop lente, et aucun réglage serveur n'y changera rien
• La résolution DNS seule devrait prendre quelques millisecondes une fois mise en cache. Une résolution constamment lente est un problème de résolveur ou de serveur de noms faisant autorité, pas un problème de serveur web

La même lecture fonctionne à l'inverse quand un seul emplacement est lent. Un temps de réflexion du serveur égal partout, avec la différence logée entièrement dans la latence et le transfert, signifie que le serveur va bien et que c'est la route qui ne va pas. Lancez la vérification depuis plusieurs endroits avant de toucher à l'application.

Mesurer tout cela au même endroit

Pour voir ces chiffres pour une page sans les assembler à la main, lancez le test de vitesse de page, qui charge la page depuis un emplacement extérieur et découpe le chargement en ses étapes. Le guide du temps de réponse serveur couvre la même mesure depuis la ligne de commande. Une seule exécution ne vous renseigne que sur cet instant précis, donc si le chiffre compte, mettez une vérification programmée dessus : HostTracker mesure le temps de réponse à chaque vérification depuis plus de 300 points de contrôle dans 158 villes, ce qui transforme une seule mesure en une référence par rapport à laquelle repérer une régression. D'autres définitions se trouvent dans la section des concepts de surveillance.