Surveillance synthétique : mesure automatisée des temps de chargement dans plusieurs régions

Ce que montre le « Synthetic Monitoring »

Synthetic Monitoring effectue automatiquement et régulièrement des contrôles prédéfinis sur un site web. Un Vérifier Elle décrit notamment l'objectif, le calendrier, les points de mesure et les critères de réussite. Chaque exécution à un point de mesure génère un résultat qui lui est propre : la configuration ne doit donc pas être assimilée à une simple mesure.

Un test de performance global ponctuel ne donne en revanche qu'un aperçu instantané dans les conditions de cette session. Répété Surveillance de sites web permet de voir si un écart se reproduit et comment les résultats évoluent au fil du temps. Pour que ces comparaisons soient pertinentes, l'objectif, l'environnement de mesure et le lieu doivent rester identifiables.

Un point de mesure public situé dans un centre de données cloud teste le site web depuis une région et une infrastructure données. Cependant, sa connexion ne correspond pas automatiquement à une connexion Internet privée sur place. Le routage, la latence du réseau et la distance par rapport à l'infrastructure de diffusion peuvent influencer le résultat ; un temps de réponse lent décrit donc dans un premier temps ce trajet de mesure spécifique.

A cours particulier répond à une autre question : elle permet de vérifier si une application est accessible depuis un réseau privé. Cela s'applique notamment aux services internes, mais ne prouve pas pour autant qu'ils soient accessibles depuis l'Internet public. À l'inverse, un test public réussi ne permet pas de savoir si l'accès fonctionne depuis n'importe quel réseau d'entreprise.

Pour la planification, il est donc utile de formuler chaque test sous forme de question concrète : la page produit est-elle accessible depuis une région cible importante, et le contenu attendu s'affiche-t-il correctement ? La réponse s'applique aux points de mesure et aux conditions de test choisis. Elle constitue une indication reproductible, mais ne reflète pas de manière exhaustive l'ensemble des visiteurs et de leurs appareils.

HTTP, navigateurs et parcours

A Vérification HTTP interroge un point de terminaison et évalue, par exemple, le code d'état ou la réponse. Pour une page produit, il peut rapidement signaler que le serveur ne répond pas comme prévu. S'il renvoie un code HTTP 200, cela signifie toutefois que seul le critère de réponse vérifié est rempli : la question de savoir si l'interface est visible et utilisable reste en suspens.

Un test de navigateur charge la même page produit dans un navigateur automatisé. Il permet de vérifier si un titre attendu s'affiche et de recueillir des mesures spécifiques au navigateur. Si ce test échoue alors que le statut HTTP est correct, il convient d'examiner le rendu et le contenu de la page. Toutefois, cette divergence ne suffit pas à elle seule à prouver l'existence d'une cause précise de l'erreur.

A Vérification du parcours va au-delà du simple chargement et exécute des étapes définies. Lors d'une connexion, par exemple, il ouvre la page de connexion, se connecte à un compte de test approprié, puis vérifie un élément attendu. Ce n'est que ce dernier critère qui permet de confirmer, pour le processus testé, que la page de connexion n'était pas seulement accessible.

Même un parcours réussi ne fait que confirmer les étapes et les conditions effectivement respectées. Une réinitialisation de mot de passe non testée ou l'utilisation d'un autre navigateur peut tout de même poser des problèmes. Choisis donc quelques processus clés pour ton entreprise et définis pour chaque étape un résultat vérifiable, plutôt que de conclure que l'ensemble du service fonctionne correctement sur la base d'un simple chargement réussi de la page.

Un contrôle visuel complémentaire permet d'examiner les modifications d'affichage qui échappent à un simple contrôle des éléments. Pour ce faire, on peut par exemple comparer des captures d'écran ; les écarts doivent ensuite être analysés, car toute modification visible n'est pas nécessairement une erreur. D'autres approches sont décrites dans l'article consacré à Vérification visuelle et contrôles automatisés du site.

Bien distinguer les temps de chargement

„Sans autre précision, le terme “ temps de chargement » ne désigne pas une grandeur clairement comparable. Lors de l'ouverture d'une page, c'est d'abord le temps nécessaire à la première réponse du serveur qui importe : il permet de situer les délais avant l'arrivée de la réponse. Cependant, il ne permet pas encore de savoir quand le navigateur a affiché quelque chose de visible ou quand il a entièrement traité la page.

Le premier rendu visible correspond à une phase ultérieure : le navigateur affiche du contenu pour la première fois. Il peut s'agir d'un court texte ou d'un autre élément initial, alors que le contenu principal de la page n'est pas encore disponible. Un affichage précoce n'est donc pas automatiquement synonyme d'une page produit rapidement utilisable.

Le Peinture au contenu le plus large (LCP) prend en compte l'apparition de l'élément de contenu le plus important dans la zone visible. Sur une page produit, il peut s'agir, par exemple, de la grande image du produit. Comparez le LCP uniquement avec des valeurs LCP désignées comme telles et notez les conditions du navigateur et du réseau ; le temps de réponse du serveur est mesuré lors d'une autre phase.

Le Durée du script Cela ne correspond toutefois pas automatiquement au temps de chargement d'une seule page. Un script peut ouvrir plusieurs pages, attendre que des éléments s'affichent et effectuer une connexion. Dans le cas des tests de navigateur Grafana-k6, la durée du script indiquée n'inclut généralement pas la phase de démarrage de k6 ; ces limites propres à l'outil doivent également être prises en compte dans l'interprétation.

L'« Interaction to Next Paint », ou INP, concerne la réactivité aux interactions. Un scénario synthétique ne peut toutefois analyser que les interactions qu'il effectue réellement. Un clic automatisé dans des conditions prédéfinies ne reflète donc pas la répartition des expériences de tous les visiteurs réels, qui utilisent d'autres appareils, connexions et parcours de navigation.

Plan de mesure pour les régions cibles

Commence le plan de mesure par les pages et les processus dont la défaillance aurait un impact sur ton activité. Il peut s'agir d'une page produit, de la page de connexion ou d'une interface. Choisis ensuite les zones de mesure en fonction de tes marchés cibles : un emplacement supplémentaire est particulièrement utile s'il couvre une région importante pour tes utilisateurs ou s'il complète une observation régionale existante.

Pour un un contrôle similaire Note le navigateur et sa version, la mise en page sur l'appareil, les conditions réseau et l'état du cache. Note également l'intervalle et le délai d'attente, ainsi que la réponse attendue ou l'élément visible. Cela permettra de déterminer ultérieurement si un écart pourrait coïncider avec une modification de l'environnement de mesure.

Le tableau suivant est un exemple conceptuel et non un plan d'exploitation mesuré ou généralement recommandé. Tu dois adapter les intervalles et les conditions d'alerte en fonction de l'importance de ton site web et des possibilités offertes par le service choisi.

Le tableau n'est qu'un point de départ : ajoutez dans la configuration du contrôle le délai précis et les autres conditions de mesure. Une alerte régionale reste pertinente en soi, même si d'autres sites signalent que tout va bien. Gardez à l'esprit qu'un point de mesure dans le cloud ne correspond pas automatiquement à une connexion Internet privée située dans la même région.

Configurer les contrôles et les procédures de test

Pour créer ta propre page de test, tu peux commencer par définir un contrôle HTTP qui vérifie le code d'état attendu. Ajoute ensuite un contrôle de navigateur qui accède à cette même page et attend l'apparition d'un en-tête attendu. Le premier test analyse la réponse du point de terminaison ; le second indique en outre si le contenu attendu s'affiche dans le navigateur.

Pour chaque exécution, consignez le lieu de mesure, l'heure, le résultat et la durée correspondante. Si le test du navigateur échoue alors que le test HTTP a réussi, examinez le contenu et le rendu, au lieu de supposer d'emblée une erreur spécifique. Vérifiez également si le titre a été modifié intentionnellement ou si le délai imparti était trop court.

Pour s'inscrire, il suffit de cliquer sur un Journey l'accès via le navigateur pour saisir des données et effectuer une vérification après la connexion. Utilisez un compte de test distinct disposant d'un minimum de droits et vérifiez un élément stable et non personnel dans la zone réservée aux utilisateurs connectés. Le simple fait que la page de connexion s'affiche correctement ne suffit pas à confirmer que la connexion fonctionne.

Choisis sélecteurs stables et attends spécifiquement les contenus attendus, au lieu de te fier uniquement à une pause fixe. Enregistre les identifiants d'accès dans la gestion des secrets du service utilisé, et non dans le script ou dans les journaux. Après toute modification de l'interface, vérifie si les sélecteurs et les critères de réussite correspondent toujours au déroulement prévu.

Limitez les scénarios de test à des actions sans risque : un parcours exécuté régulièrement ne doit pas donner lieu à de véritables commandes ou paiements. Si une étape impliquant une écriture est inévitable, elle doit être effectuée dans un environnement de test expressément prévu à cet effet ou dans le cadre d'un processus de test contrôlé. Déterminez également qui est chargé d'analyser un cycle ayant échoué et de gérer les données de test.

Comparer les outils et les modèles d'exploitation

Lors du choix d'un outil, tu dois faire la distinction entre un service de surveillance géré et un outil qui, dans un premier temps, se contente d'effectuer un simple test. Le fait qu'un navigateur soit pris en charge n'est pas le seul critère déterminant : tu as également besoin de sites adaptés, d'une exécution régulière, d'un archivage des résultats et d'un système d'alerte adapté à ton activité.

Grafana Cloud Surveillance synthétique associe des configurations de vérification à des sondes publiques et privées et prend en charge les vérifications de navigateur basées sur k6. Les points de mesure publics et privés répondent à des questions différentes en matière d'accessibilité. Vérifiez également au préalable les fréquences de vérification disponibles : les vérifications de navigateur et de script sont soumises à d'autres limites que certaines vérifications simples des terminaux.

Ce qui est exécuté localement Module de navigateur k6 Il faut le dissocier de cela. Pour cela, tu as besoin de k6 et d'un navigateur basé sur Chromium ; l'exécution d'un script local ne configure ni automatiquement de points de mesure régionaux, ni de planning permanent. Pour une surveillance distribuée, tu devrais organiser en plus l'exécution, l'infrastructure et la gestion des résultats, ou utiliser un service adapté.

AWS CloudWatch Synthetics exécute les « canaries » planifiés. Les Fonction multilocalisation réplique un Canary dans les régions AWS sélectionnées et regroupe les résultats dans une région principale. Avant le déploiement, vérifiez les versions minimales documentées pour les environnements d'exécution Node.js Puppeteer ou Playwright pris en charge, ainsi que la disponibilité régionale spécifique de cette fonctionnalité.

Les sondes que vous exploitez vous-même vous offrent davantage de contrôle sur leur emplacement et leur environnement, mais nécessitent également une maintenance, des mises à jour et une surveillance de l'infrastructure de mesure. Pour tous les modèles d’exploitation, compare les emplacements réellement proposés, les coûts liés à l’utilisation et les conditions de conservation des données. Vérifie notamment où sont stockées les captures d’écran et les journaux, et si cela est conforme à tes exigences en matière de protection des données.

Analyser judicieusement les résultats régionaux

Comparez les résultats régionaux pour la même page et la même période. Le navigateur, la version, les conditions réseau et l'état du cache doivent être identiques ; dans le cas contraire, une différence peut être due à l'environnement de mesure plutôt qu'à la diffusion. De plus, un point de mesure dans le cloud reflète un emplacement et un chemin réseau spécifiques, et non l'ensemble des connexions d'une région.

Lorsque les mesures sont réussies à plusieurs reprises, le Médiane la valeur médiane des résultats triés. Un centile supérieur, par exemple le 95e centile, met en évidence les courses les plus lentes : 95 % des valeurs considérées ne dépassent pas cette valeur. Notez à cet effet la période et le nombre de mesures, afin de pouvoir évaluer l'étendue de l'analyse.

Lorsque le nombre d'exécutions est faible, un seul test lent peut fortement influencer le centile supérieur. Vérifie donc l'évolution dans le temps et compare plusieurs fenêtres de mesure avant de conclure à une détérioration régionale durable. Un changement de point de mesure ou de version du navigateur doit également être pris en compte comme un facteur susceptible d'influencer l'analyse.

Attends tentatives infructueuses affichées séparément, par exemple sous forme de nombre d'erreurs et de pourcentage par rapport à l'ensemble des exécutions. Sinon, une statistique sur les temps de chargement ne prenant en compte que les appels réussis peut donner une fausse impression de bon fonctionnement d'une région où les délais d'attente sont fréquents. En cas d'échec sans valeur de temps de chargement valide, il n'est pas possible d'utiliser simplement un temps de chargement normal.

Le Real User Monitoring complète les tests contrôlés en intégrant l'expérience des visiteurs réels. Le rapport Chrome UX fournit des données de terrain disponibles sur une période glissante de 28 jours ; toutes les pages ou tous les groupes d'utilisateurs n'y sont pas couverts. Cette vision à plus long terme ne remplace donc pas une alerte synthétique actuelle et ne peut pas non plus être assimilée directement à un seul test.

Alertes et dépannage régional

A alarme globale peut regrouper les erreurs récurrentes sur plusieurs sites. Cela permet de distinguer un incident de grande ampleur d'un dysfonctionnement isolé sur un point de mesure. Définissez également un critère d'alerte régional : si un marché cible important est en panne, le succès des autres régions ne doit pas masquer le problème.

Choisissez le nombre de répétitions et la durée en fonction de l'importance du processus. Plusieurs tests échoués consécutifs peuvent masquer des anomalies ponctuelles, mais retardent la notification. Surveillez également les points de mesure eux-mêmes et vérifiez si un échantillon est défectueux ou si d'autres tests effectués au même endroit sont également concernés.

Si une page produit est lente sur un seul site, commence par comparer des sessions similaires et identifie le moment où l'écart est apparu. Examinez ensuite la résolution DNS, la diffusion via le CDN, les temps de chargement des ressources et la réponse du serveur. Les différents chemins réseau et la proximité de l'infrastructure peuvent influencer les niveaux de référence régionaux ; la valeur mesurée à elle seule ne permet pas encore d'identifier la cause.

Pour les ressources provenant d'autres origines, les détails relatifs aux mesures du navigateur peuvent être limités. Sans un Timing-Allow-Origin- Dans les en-têtes, certaines valeurs de l'API Resource Timing peuvent être nulles. Cela ne signifie pas automatiquement que la connexion était extrêmement rapide ; vérifie d'abord quelles informations le serveur tiers met à disposition pour la mesure.

Pour passer au niveau d'analyse suivant, associez l'heure, la région et le processus concerné aux logs et traces disponibles. Cela permet, par exemple, de rechercher une requête lente sans pour autant tirer de conclusion définitive quant à sa cause à partir d'une simple corrélation. L'article consacré à Observabilité dans l'hébergement.

Assurer un suivi continu

Commencez par des vérifications simples des terminaux pour les cibles importantes accessibles au public, puis complétez-les par des parcours de navigation ciblés pour les pages ou les connexions critiques pour l'entreprise. Un test HTTP peut être exécuté plus fréquemment, tandis que le test par navigateur, plus complexe, vérifie des fonctionnalités sélectionnées. Tu définis les intervalles en fonction du délai de détection souhaité, des limites de service et des coûts, et non en fonction d’une durée forfaitaire en minutes.

Pour chaque vérification, détermine une Compétence: Qui reçoit l'alerte, qui vérifie le service concerné et qui gère le point de mesure ? Précisez également à quel moment une alerte est transmise et où se trouvent les résultats correspondants. Une vérification sans réaction face à des erreurs récurrentes fournit certes des données, mais ne résout pas l'incident.

Après toute modification de l'interface, vérifie que les sélecteurs et les contenus attendus correspondent toujours au déroulement prévu. Dans le script, attends l'élément requis au lieu de te fier uniquement à un délai fixe. Documente les modifications apportées au navigateur, au profil réseau ou aux paramètres de cache afin d'éviter que des comparaisons ultérieures ne mélangent, sans que tu t'en rendes compte, des conditions de mesure différentes.

Considérez les captures d'écran et les journaux comme des données potentiellement sensibles : ils peuvent contenir le contenu d'une session ou des informations provenant de l'application. Limitez l'accès et la conservation en fonction de l'objectif visé et vérifiez ce que le test enregistre réellement. Pour les connexions, utilise un compte de test aux fonctionnalités limitées et gère les identifiants en tant que « secrets » plutôt que dans le script.

Vérifie régulièrement si Sites de mesure correspondent toujours à vos marchés cibles et si les tarifs, la gestion des données et les exigences en matière de protection des données permettent toujours son fonctionnement. Dans le cas de serveurs Probes gérés en interne, il faut également tenir compte de la mise à jour et de la surveillance de l'environnement. Un script de navigateur k6 lancé localement ne constitue pas à lui seul une infrastructure de surveillance distribuée à long terme.