Application: Mesurez le temps de réponse de votre site Web avec cet outil de métriques simples

Lorsqu’un site Web se charge lentement, il n’est pas toujours clair ce qui est à blâmer. Est-ce le DNS fournisseur? Le serveur lui-même? Ou quelque chose entre les deux? Pour aider les professionnels du Web à identifier où des retards se produisent, j’ai publié cet outil sur ce site qui mesure le cycle de vie complet d’un Http Demande, de la résolution du domaine à la livraison de contenu.

Cet outil basé sur un navigateur utilise des diagnostics côté serveur pour simuler une demande HTTP réelle et décomposer ses composants de synchronisation. Il peut être utile que vous auditez votre domaine, en dépannant un partenaire à chargement lent APIou tout simplement analyse comparative Monnaie Performance entre les URL.

Utilisez l’outil ci-dessous pour analyser les performances de toute orientation publique URL:

Comment lire les résultats

Lorsque vous exécutez un test, l’outil exécute un live cURL Demande et rapports des informations de synchronisation détaillées en secondes. Voici ce que signifie chacune des mesures signalées:

• Temps de recherche DNS: Cela fait référence au temps nécessaire pour résoudre un nom de domaine à son correspondant Adresse IP. Si ce nombre est élevé, il peut indiquer des serveurs de nom lents, des problèmes de propagation DNS ou de mauvaises performances du fournisseur DNS. Google recommande de garder cela moins de 50 ms, avec quelque chose de plus de 100 ms considéré comme un goulot d’étranglement potentiel.
• Heure de connexion TCP: Cela mesure le temps qu’il faut pour établir une connexion TCP avec le serveur. Les retards ici pourraient indiquer la latence du réseau, les pare-feu ou la distance au serveur d’origine. Les valeurs inférieures à 100 ms sont préférées; Des temps cohérents supérieurs à 150 ms peuvent indiquer les inefficacités de réseau ou de routage.
• Temps de poignée TLS (Https seulement): si la demande est faite sur HTTPS, ce nombre reflète le temps passé à négocier la connexion sécurisée. Des suites de chiffre d’affaires obsolètes, des certificats expirés ou des serveurs de bord surchargés peuvent provoquer une longue TLS poignée de main. Google considère tout ce qui est optimal de moins de 100 ms, tandis que plus de 200 ms pourraient être symptomatiques de la sécurité ou des erreurs de configuration des performances.
• Temps de pré-transfert: Cela inclut DNS, TCPet TLS – tout qui se produit avant l’envoi de la demande réelle. Il reflète l’heure de démarrage cumulative avant que le serveur ne commence à traiter la demande. Les temps pré-transfert idéaux se situent entre 100 et 300 ms; Tout ce qui est au-delà de 400 ms devrait être étudié en phase par phase.
• Il est temps de premier octet (Ttfb): Cette métrique mesure le temps nécessaire au serveur pour commencer à envoyer une réponse après la demande de la demande. Un TTFB élevé peut indiquer des retards côté serveur tels que les requêtes de base de données lentes, le contenu dynamique non acheté ou les mauvaises performances du serveur. Les directives de Google sont de maintenir le TTFB sous 200 ms; Les valeurs persistantes de plus de 500 ms suggèrent des problèmes de backend ou d’infrastructure.
• Temps de transfert total: Il s’agit de la durée complète du début de la demande jusqu’à ce que l’octet final soit reçu. Si votre TTFB est rapide mais que le temps total est lent, il peut être dû à la taille de la réponse, à la limitation du serveur ou à des retards de livraison de contenu. Visez moins de 500 ms pour les charges utiles HTML sur le haut débit; Plus d’une seconde peut indiquer des actifs non compressés ou une livraison inefficace.
• Code d’état HTTP: C’est le code de réponse Retourné par le serveur (par exemple, 200 pour le succès, 301/302 pour les redirections, 404 pour non trouvé). Il donne un contexte pour la façon dont le serveur a géré la demande.

Cet outil ne simule pas seulement une demande – elle l’exécute en direct sur mon serveur en utilisant PHP cURL bibliothèque. Cela signifie que vous voyez ce que le serveur voit, pas seulement ce que votre navigateur perçoit. Il est pratique pour le débogage des problèmes de performances qui peuvent ne pas être visibles de votre réseau local.

Essayez l’outil et n’hésitez pas à tester une variété d’URL – votre page d’accueil, un point de terminaison API spécifique ou une ressource distante sur laquelle vous comptez. Plus votre compréhension de ces mesures de synchronisation est profonde, plus vous pourrez diagnostiquer et améliorer vos performances Web.