Comment diagnostiquer un chargement lent dans certaines régions ? Les équipes de maintenance peuvent commencer par mesurer les performances par zone géographique, puis identifier progressivement les éventuels goulots d’étranglement au niveau du DNS, du CDN ou du serveur. L’essentiel est de comparer les données d’accès de différentes régions pour déterminer à quelle étape le ralentissement se produit.
Un accès lent dans certaines régions ne signifie pas nécessairement que les performances du serveur sont insuffisantes. Le problème peut également être lié au réseau de l’opérateur local, au taux de succès du cache ou à des scripts tiers. Commencez par conserver les éléments attestant du dysfonctionnement, puis examinez le parcours de la requête afin d’éviter les changements inutiles et les échanges répétés.
Il est recommandé de suivre le processus « reproduire le problème, décomposer les temps de chargement, vérifier les hypothèses, effectuer un nouveau test et clôturer ». À chaque étape, consignez la région de test, le réseau, l’heure et la page concernée. Vous pourrez ainsi comparer les résultats avant et après intervention et informer le client de l’avancement du traitement.
Commencez par préciser « dans quelle région et de quelle manière le chargement est lent »
Après avoir reçu un signalement, recueillez d’abord le pays et la ville du client, son opérateur réseau, l’URL consultée, l’heure de l’incident et le fuseau horaire correspondant. Demandez également s’il utilise un téléphone ou un ordinateur, ainsi qu’un réseau mobile ou celui de son lieu de travail, afin de ne pas confondre un problème propre à un réseau avec une panne régionale.
Demandez au client de décrire précisément le problème : le nom de domaine met-il longtemps à répondre, la page reste-t-elle blanche, le texte apparaît-il avant que les images ne se chargent beaucoup plus tard, ou l’envoi du formulaire reste-t-il en attente ? Ces symptômes correspondent à différentes pistes de diagnostic ; il ne suffit pas de résumer la situation par « le site est lent à s’ouvrir ».
Choisissez la région du client, une autre ville de la même région et une région où le site fonctionne normalement, puis testez la même page. Privilégiez un navigateur utilisé localement ou un nœud de test régional fiable, et indiquez l’opérateur du nœud. Ne vous fiez pas au seul nom du pays pour évaluer la couverture.
Effectuez trois à cinq tests par nœud. Consignez séparément les résultats de la première visite et des visites suivantes, et testez également la page d’accueil, une page de détail produit et la page de demande de renseignements. Si le problème ne survient qu’à certaines heures, effectuez de nouveaux tests pendant la plage horaire indiquée par le client.
Consultez le graphique en cascade du chargement pour repérer les délais
Dans l’onglet Réseau des outils de développement du navigateur, conservez le journal des requêtes et examinez les temps de chargement du document principal et des ressources essentielles. Distinguez d’abord la résolution du domaine, l’établissement de la connexion, l’attente du premier octet et le téléchargement des ressources, puis déterminez si le ralentissement vient du réseau ou de la page elle-même.
Si la résolution du domaine est lente, vérifiez en priorité le DNS. Si l’établissement de la connexion ou la négociation TLS prend du temps, examinez le réseau, les pertes de paquets et la réutilisation des connexions. Si l’attente du premier octet augmente nettement, poursuivez les vérifications sur le retour depuis le CDN vers le serveur d’origine, le traitement de l’application et les réponses de la base de données.
Le temps jusqu’au premier octet comprend à la fois le temps de transmission sur le réseau et l’attente côté serveur. Une valeur élevée ne prouve donc pas à elle seule que la puissance de calcul du serveur est insuffisante. Si le document principal se charge rapidement, mais que le premier écran apparaît tardivement, examinez en priorité les images volumineuses, les scripts bloquants, les polices et la charge de rendu du navigateur.
Si vous pouvez utiliser la ligne de commande, servez-vous de curl pour consigner les durées de résolution, de connexion, de négociation TLS, jusqu’au premier octet et de la requête totale. Certains champs indiquent un temps cumulé depuis le début de la requête : pour évaluer la durée de chaque étape, calculez les écarts et ne les additionnez pas comme s’il s’agissait de durées indépendantes.
Si le ralentissement ne touche que certaines régions, vérifiez d’abord le DNS et le CDN
Comparez les résultats de résolution dans les régions touchées et dans celles où l’accès est normal. Vérifiez l’absence d’enregistrements invalides, d’un routage géographique incorrect ou d’une chaîne de résolution trop longue. Des adresses différentes selon les régions peuvent résulter d’un routage normal ; évaluez la situation en tenant compte de la connectivité réelle et du temps d’accès.
Si les enregistrements DNS ont été modifiés récemment, vérifiez les enregistrements faisant autorité, le cache des résolveurs récursifs et le délai de propagation. Ne concluez pas au rétablissement mondial simplement parce que le site est de nouveau accessible depuis votre réseau local. Évitez aussi de modifier fréquemment les paramètres DNS : les différences de cache rendraient le diagnostic encore plus difficile.
Dans la console du CDN et dans les en-têtes de réponse, vérifiez le nœud périphérique, l’état du cache, le taux de succès du cache et le temps de réponse du serveur d’origine. Si les ressources statiques ne sont toujours pas servies depuis le cache dans les régions lentes, vérifiez les règles de cache, les paramètres de requête, les cookies et les en-têtes de réponse du serveur d’origine susceptibles d’influer sur la mise en cache.
Si le problème ne concerne qu’un opérateur particulier, transmettez au fournisseur du CDN l’heure, l’URL, les informations sur le nœud et l’identifiant de la requête. Le traçage de route peut aider à localiser le problème, mais l’absence de réponse d’un nœud intermédiaire ou la restriction du trafic de sondage ne signifie pas que les requêtes réelles subissent des pertes de paquets à cet endroit.
Comment distinguer un ralentissement du serveur d’origine d’un chargement lent des ressources de la page ?
Si le temps jusqu’au premier octet augmente dans plusieurs régions et que le temps de réponse du CDN vers le serveur d’origine augmente également, consultez les journaux du serveur d’origine pour examiner les réponses de l’application. À partir des requêtes enregistrées sur la même période, recherchez les interfaces lentes, le taux d’erreur, les requêtes lentes de la base de données et l’utilisation du pool de connexions.
Vérifiez également si le processeur, la mémoire, les opérations de lecture et d’écriture sur le disque ou la bande passante subissent une saturation prolongée. Ne vous limitez pas au taux d’utilisation à un instant donné : comparez les tendances pendant la période de l’incident afin de déterminer si elles sont liées à une variation de charge due à une campagne publicitaire, à l’activité de robots d’exploration ou à des tâches par lots.
Pour comparer l’accès via le CDN et la réponse du serveur d’origine, les équipes de maintenance doivent effectuer les tests dans un environnement contrôlé, en conservant le même domaine, le même certificat et les mêmes conditions de requête. Le résultat obtenu en contournant le CDN peut aider au diagnostic, mais ne permet pas d’ignorer les différences de cache ni l’influence des règles de sécurité sur la réponse.
Si le document principal est normal, mais que les images se téléchargent lentement, vérifiez leur poids, leur format et leurs dimensions. Si les ressources sont déjà téléchargées, mais que la page reste lente, examinez l’exécution des scripts et l’utilisation du thread principal. La grande image du premier écran doit être chargée en priorité ; envisagez le chargement différé pour les images situées plus bas dans la page.
N’oubliez pas les outils de chat, les polices et les scripts marketing
Les sites de marketing international intègrent souvent des outils de chat en ligne, des systèmes de suivi publicitaire, des cartes, des vidéos et des services multilingues. Si un domaine tiers est instable dans une région donnée, certaines fonctionnalités peuvent rester en attente et, dans certains cas, un script synchrone peut bloquer l’affichage de toute la page.
Dans un environnement de test ou localement dans le navigateur, bloquez les requêtes suspectes une par une, puis comparez le temps d’affichage du premier écran et le temps d’interactivité. Si le site fonctionne de nouveau après la désactivation d’un service, vérifiez s’il se trouve sur le chemin critique de chargement avant de décider de le charger de façon asynchrone ou différée, ou de le remplacer.
Lors de l’optimisation des scripts marketing, vérifiez en parallèle le suivi, les conversions publicitaires et les fonctions de demande de renseignements afin d’éviter d’accélérer la page au prix d’une perte de données métier. Pour le formulaire de demande de renseignements, testez également séparément la réponse de l’interface et le message de confirmation. Ne mettez pas fin au diagnostic en vérifiant uniquement que la page s’ouvre.
Si vous utilisez une plateforme de création de sites et de marketing telle que 易营宝, transmettez à l’assistance technique le site, les pages, les régions et les requêtes anormales. Déterminez d’abord les périmètres de maintenance respectifs de la plateforme, du CDN, du fournisseur de noms de domaine et des extensions tierces afin de faciliter la coordination.
Dans quelles conditions peut-on considérer le problème comme résolu ?
Ne modifiez qu’une variable principale à la fois et consignez l’heure, le contenu et la procédure de retour arrière de chaque modification. Après chaque changement, effectuez de nouveaux tests depuis la même région, avec le même réseau et sur la même page. Comparez les médianes et l’évolution des requêtes les plus lentes au lieu de considérer un accès rapide isolé comme une preuve de résolution.
La validation doit couvrir l’affichage du premier écran, l’interactivité de la page, le chargement des images et l’envoi du formulaire. Demandez également au client à l’origine du signalement de vérifier le résultat. Si une mesure réelle de l’expérience utilisateur est disponible, observez les tendances par pays, appareil et réseau afin de compenser les différences entre l’environnement des nœuds de test et celui des clients.
Pour diagnostiquer un chargement lent dans certaines régions à l’étranger, l’essentiel est de s’appuyer sur des données comparatives pour circonscrire le problème à la résolution DNS, au réseau, au cache, au serveur d’origine ou aux ressources de la page. Dans le compte rendu, indiquez les éléments attestant de l’anomalie, les mesures prises, les résultats des nouveaux tests et les points restant à surveiller, afin d’assurer un suivi complet de l’incident.
