Comment vérifier le temps de réponse serveur

Temps de réponse, TTFB et chargement de page ne sont pas le même chiffre

Ces termes sont utilisés de façon interchangeable alors qu'ils répondent à des questions différentes :

• Le temps de connexion est la résolution DNS plus la poignée de main TCP plus la poignée de main TLS. C'est surtout une affaire de distance et de qualité réseau, et le code du serveur lui-même n'y est pour rien.
• Le temps jusqu'au premier octet (TTFB) est le moment où le premier octet de la réponse arrive, mesuré depuis le début de la requête. Il inclut le temps de connexion plus le traitement du serveur : routage, requêtes de base de données, rendu de gabarit, tout appel API en amont.
• Le temps de traitement serveur est le TTFB moins le temps de connexion. C'est la partie que vous pouvez corriger dans votre application.
• Le temps de chargement de page englobe tout : le HTML, puis chaque image, feuille de style, script et police que le navigateur récupère, plus le travail de les afficher. Une page peut avoir un excellent TTFB et pourtant mettre huit secondes à charger.

Les confondre pousse les gens à optimiser la mauvaise chose. Compresser des images ne fait rien pour une requête de base de données lente, et une base de données plus rapide ne fait rien pour une page transportant quatre mégaoctets de JavaScript.

Le mesurer avec curl

curl rapporte chaque phase séparément, ce qui permet de séparer le coût de connexion du coût serveur en une seule commande :

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

Toutes les valeurs sont en secondes depuis le début de la requête, donc chacune inclut celles qui la précèdent. Le traitement serveur est ttfb moins tls, ou moins connect en HTTP simple. Lancez-la trois ou quatre fois : la première requête peut payer un cache froid ou une connexion neuve, et un seul échantillon n'est pas une mesure.

Deux points à garder en tête. Cela ne mesure que le document HTML, pas la page entière, donc ce sera toujours plus rapide en apparence qu'un test dans un navigateur. Et une page non mise en cache, connectée ou de recherche est souvent nettement plus lente que la page d'accueil, donc mesurez l'URL qui vous intéresse plutôt que /.

Ce qui compte comme normal

Il n'existe pas de seuil universel. Ces tranches constituent un guide de travail raisonnable pour une requête de document mesurée depuis un emplacement proche de vos visiteurs :

• Moins de 200 ms. Rapide. Typique d'un contenu statique, d'un cache chaud, ou d'une bordure CDN qui répond directement.
• 200 à 500 ms. Normal pour une page dynamique qui interroge une base de données. Personne ne le remarque.
• 500 ms à 1 s. Perceptible. Généralement une requête qui a besoin d'un index, un gabarit non mis en cache, ou un appel amont lent.
• 1 à 3 s. Les utilisateurs le ressentent, et les moteurs de recherche le mesurent. Cela mérite d'être traité comme un défaut.
• Plus de 3 s. Quelque chose ne va pas : un serveur saturé, un verrou, un service amont qui expire, ou une requête qui fait bien plus de travail qu'elle ne devrait.

La comparaison la plus utile est celle que vous faites avec vous-même. Une page qui répondait en 300 ms le mois dernier et répond en 900 ms aujourd'hui a une cause précise introduite entre les deux, et le savoir vaut plus que n'importe quel repère publié.

Pourquoi cela varie selon l'emplacement

La distance coûte du temps et ne peut pas être optimisée. Chaque aller-retour entre le client et le serveur prend au moins aussi longtemps que le chemin physique le permet, et une connexion TLS nécessite plusieurs allers-retours avant même que le premier octet de la réponse ne puisse commencer. C'est pourquoi le même serveur peut répondre en 150 ms localement et en 700 ms depuis un autre continent tout en effectuant exactement le même travail.

Le routage compte aussi, et il est moins prévisible que la distance : le trafic entre deux réseaux peut emprunter un mauvais chemin qui ajoute de la latence pour une région et pas pour les autres. Si vous utilisez un CDN, certains emplacements sont servis depuis une copie mise en cache à proximité tandis que d'autres ratent le cache et paient le trajet complet jusqu'à l'origine, ce qui produit un écart important entre les emplacements pour la même URL.

Mesurez donc depuis l'endroit où se trouvent vos utilisateurs, pas depuis celui où se trouve votre serveur, et comparez des choses comparables. Un chiffre sans emplacement associé n'est comparable à rien.

Quand la lenteur signifie une panne

Certaines lenteurs sont un avertissement plutôt qu'un problème de performance :

• Un temps de réponse qui augmente régulièrement sous charge signifie que le serveur est saturé. Cela finit en timeouts, pas seulement en pages lentes.
• Des temps regroupés à exactement 30 ou 60 secondes sont des timeouts, pas de la lenteur. Quelque chose en amont ne répond pas et un proxy attend d'atteindre sa limite avant d'abandonner avec un 504.
• Rapide la plupart du temps avec des pics énormes occasionnels pointe généralement vers un verrou, une tâche cron, une sauvegarde, ou un cache qui expire et que chaque requête reconstruit en même temps.
• Lent uniquement pour les utilisateurs connectés signifie que le cache absorbe le trafic anonyme et masque une application réellement lente en dessous.
• Lent depuis une seule région est un problème de réseau ou de CDN, pas un problème d'application, et aucune quantité de travail côté serveur ne le corrigera.

Remarquer le jour où ça a changé

Une seule mesure vous renseigne sur ce qui s'est passé pour une requête, depuis un endroit, à un instant donné, et le temps de réponse est exactement le genre de métrique qui dérive plutôt que de casser franchement. Les vérifications programmées mesurent la même URL depuis les mêmes emplacements en continu, conservent l'historique pour que vous puissiez pointer le jour où cela a changé, et alertent quand le temps franchit un seuil plutôt que quand un client se plaint. HostTracker exécute ces vérifications depuis plus de 300 points de contrôle dans 158 villes, donc un ralentissement régional se voit comme tel. Lancez une vérification maintenant avec l'outil de vérification HTTP. Quand le serveur est rapide et que la page ne l'est toujours pas, le reste de la réponse se trouve dans comment vérifier la vitesse d'un site web.