Le temps jusqu'au premier octet, c'est la durée entre la demande et l'arrivée du premier octet de la réponse. Il contient le DNS, la connexion, la poignée de main et la réflexion du serveur - et curl imprime chaque partie séparément, si bien que vous voyez laquelle.
curl -o /dev/null -s -w 'dns %{time_namelookup}\nconnect %{time_connect}\ntls %{time_appconnect}\nttfb %{time_starttransfer}\ntotal %{time_total}\n' https://yourdomain.com/
Le lire
- dns élevé - un résolveur lent, ou un TTL très bas qui force une résolution à chaque fois.
- connect élevé - la distance. Un serveur sur un autre continent ne se corrige pas avec du code.
- tls moins connect élevé - la poignée de main. Une chaîne de certificats incomplète oblige le navigateur à aller chercher la partie manquante.
- ttfb moins tls élevé - le serveur qui construit la page. C'est celui-là que vous pouvez corriger.
Ce qui est bon
- Sous 200 ms - le serveur n'est pas votre problème. Regardez du côté du navigateur.
- 200-500 ms - normal pour une page dynamique sans cache.
- Au-dessus de 800 ms - quelque chose de précis est lent, et il vaut mieux le trouver que le recouvrir de cache.
Mesurez la même URL plusieurs fois. La première requête après un déploiement est lente pour des raisons qui ne toucheront jamais un visiteur - caches froids, opcache vide - et une seule mesure de cela ne vous apprend rien.
Mesurez depuis là où sont vos visiteurs
Un TTFB mesuré depuis le serveur lui-même exclut totalement le réseau et est toujours excellent. Ce n'est pas non plus ce que vit qui que ce soit.
Si le TTFB est bon et que la page paraît quand même lente, cessez d'optimiser le serveur. Le temps est dans le navigateur, et aucune quantité de cache n'y changera rien.
