Pourquoi le site reste-t-il lent alors qu’il dispose de nœuds CDN en Amérique du Sud ?

Vous avez déployé un CDN en Amérique du Sud, mais votre site reste lent. En général, trois points sont à vérifier : les visiteurs sont-ils dirigés vers un nœud adapté, les requêtes sont-elles servies depuis le cache et, en cas de défaut de cache, le retour vers le serveur d’origine se déroule-t-il correctement ? La présence de sites sud-américains sur la carte des nœuds indique uniquement que le service peut y être fourni ; elle ne prouve pas qu’une visite donnée a effectivement bénéficié d’une accélération efficace.

Pour effectuer le diagnostic, commencez par noter la page concernée, l’heure de la visite, la ville et l’opérateur. Consultez ensuite les requêtes réseau dans le navigateur. Le simple fait qu’« un client au Brésil trouve le site lent » ou les résultats d’un test de vitesse effectué en Chine ne permettent pas de distinguer facilement un problème de réseau, de temps de réponse du serveur ou de lenteur de la page elle-même.

Commencez par déterminer si le ralentissement concerne la connexion, le premier octet ou l’affichage de la page

Ouvrez le panneau Network des outils de développement du navigateur, désactivez le cache du navigateur, puis rechargez la page. Observez en particulier le document de la page, la grande image visible au premier écran et les principaux scripts. Cela permet de mieux distinguer les effets du cache local du navigateur de ceux du cache CDN.

• Durée importante pour le DNS, la connexion ou TLS : vérifiez en priorité la résolution du domaine, la sélection du nœud et la route réseau utilisée.
• Temps d’attente du premier octet élevé : le traitement en périphérie, un défaut de cache, le réseau vers le serveur d’origine ou les calculs effectués par celui-ci peuvent être en cause ; n’attribuez pas directement le problème aux performances du serveur.
• Le document se charge rapidement, mais le contenu tarde à s’afficher : vérifiez les grandes images, les scripts qui bloquent le rendu, les polices et les composants tiers.

Par exemple, si le texte de la page produit apparaît, mais que l’image principale tarde à se charger, examinez la requête de l’image au lieu de continuer à modifier le cache du document de la page. Si toute la page attend la première réponse, examinez ensuite le chemin entre le CDN et le serveur d’origine.

La présence de nœuds en Amérique du Sud ne garantit pas que les requêtes empruntent la route la plus adaptée

Les interconnexions réseau varient selon les pays, les villes et les opérateurs d’Amérique du Sud. Un nœud géographiquement plus proche ne garantit pas une route plus fluide ; certains réseaux peuvent faire transiter le trafic par d’autres régions. La sélection des nœuds peut également dépendre du DNS récursif, des interconnexions entre opérateurs et de la charge des nœuds.

Vérifiez d’abord dans la console du CDN que le domaine de votre service est activé dans la région ciblée. Vérifiez ensuite la configuration du DNS faisant autorité et confirmez que les résultats de résolution obtenus localement sont conformes aux exigences du fournisseur de services. Si vous utilisez une connexion CNAME, assurez-vous que l’enregistrement ne pointe pas encore vers une ancienne plateforme ou vers le serveur d’origine.

Ensuite, combinez l’identifiant du nœud figurant dans les en-têtes de réponse, les journaux du CDN et les tests effectués localement pour confirmer où la requête est traitée. La signification des identifiants de nœud varie selon les plateformes : ne vous fiez pas uniquement à une base de données de géolocalisation IP et ne considérez pas un seul ping comme une mesure complète de l’expérience de navigation.

Les tests doivent couvrir les villes et les réseaux où se trouvent vos principaux clients. Si une même page fonctionne normalement sur une connexion fixe, mais est lente sur un réseau mobile, il faut souvent examiner plus en détail le chemin emprunté par l’opérateur. Si IPv6 est activé, comparez également IPv4 et IPv6 séparément afin qu’un problème sur l’une des routes ne soit pas masqué par une moyenne générale.

Un taux de cache global élevé ne signifie pas que cette page a été servie depuis le cache

Le taux de cache global affiché dans la console peut être élevé en raison d’un grand nombre de petites images, tandis que les pages de destination publicitaires et les pages de détail des produits continuent de solliciter fréquemment le serveur d’origine. Vérifiez l’état du cache pour chaque requête lente. Les en-têtes Cache-Control et Age, ainsi que les indicateurs de cache fournis par la plateforme, peuvent donner des indices ; interprétez-les en tenant compte des règles propres à cette plateforme.

Parmi les situations qui entraînent des retours fréquents au serveur d’origine, on trouve les réponses du serveur d’origine comportant private ou no-store, le contournement du cache déclenché par les requêtes contenant des cookies, les paramètres d’URL inclus dans la clé de cache et la multiplication des copies en cache pour les différentes versions linguistiques ou mobiles. Les pages rarement consultées peuvent également être renvoyées au serveur d’origine lorsque leur cache expire ou qu’elles sont évincées.

Pour les campagnes de promotion à l’international, prêtez une attention particulière aux paramètres de suivi publicitaire. Si chaque adresse d’une même page de destination, assortie de paramètres différents, crée une entrée distincte dans le cache, le taux de réutilisation diminue. Vous pouvez modifier la clé de cache pour les paramètres de suivi dont vous avez confirmé qu’ils n’ont aucune incidence sur le contenu, mais ne négligez pas ceux qui déterminent la langue, la devise, les spécifications ou l’identité de l’utilisateur.

Avant d’optimiser le cache, définissez clairement les limites du contenu concerné. Les images, feuilles de style et scripts publics se prêtent généralement à une mise en cache de longue durée. Les envois de demandes de renseignements, les paniers, les sessions de connexion et les prix personnalisés doivent être configurés séparément. Forcer la mise en cache de toutes les requêtes risque d’entraîner des mélanges d’informations ou des erreurs lors des envois.

Si les requêtes avec cache sont rapides et celles sans cache sont lentes, poursuivez le diagnostic sur le chemin vers le serveur d’origine

À partir d’une même région et à des heures proches, envoyez plusieurs fois une requête pour la même ressource et comparez les temps de réponse en tenant compte de l’état du cache. Si les requêtes sans cache sont nettement plus lentes et que les requêtes avec cache retrouvent une durée normale, orientez le diagnostic vers le chemin de retour au serveur d’origine. La lenteur d’une première visite peut aussi être liée au DNS ou à l’établissement de la connexion : ne tirez donc pas de conclusion sur la seule base de la différence perçue entre deux chargements.

Analysez séparément le temps de retour au serveur d’origine : le nœud en périphérie met-il longtemps à se connecter au serveur, ou le serveur met-il du temps à générer le contenu après avoir reçu la requête ? Dans le premier cas, vérifiez la région du serveur d’origine, le réseau interrégional, la réutilisation des connexions et le pare-feu du serveur d’origine. Dans le second, examinez les journaux de l’application, les requêtes à la base de données et la présence d’appels synchrones à d’autres API lors du chargement de la page.

Si le serveur d’origine se trouve en Asie alors que les clients sont principalement en Amérique du Sud, les requêtes dynamiques peuvent toujours subir de longs temps de transit entre les régions. L’ajout d’un cache statique ne supprimera pas cette attente. Évaluez, selon les besoins de votre activité, la mise en place de serveurs d’origine régionaux, d’un cache hiérarchisé ou d’une optimisation du chemin dynamique. Toutefois, une migration de serveur doit également tenir compte des autres marchés, de la synchronisation des données et des coûts d’exploitation.

Même si la page s’ouvre, les composants marketing peuvent encore ralentir son utilisation

Lorsqu’un même site sert à la création de sites, au SEO, à la diffusion de publicités et à l’acquisition de trafic depuis les réseaux sociaux, le service client en ligne, les vidéos intégrées, les scripts d’analyse, les polices et les API de formulaires peuvent provenir de domaines différents. La connexion du site principal à un CDN n’accélère pas automatiquement ces requêtes externes.

Examinez le graphique en cascade des requêtes pour repérer les dépendances du contenu visible au premier écran. Commencez par compresser l’image principale, générer des images adaptées à la taille de l’écran et retarder le chargement des composants non essentiels. Ne supprimez pas les codes de suivi uniquement pour améliorer le score d’un test de vitesse : vérifiez que l’attribution publicitaire, les formulaires de demande de renseignements et le processus d’achat fonctionnent toujours correctement après les modifications.

Conservez une comparaison avant/après pour chaque modification : utilisez la même région, le même réseau et la même page, puis consignez les résultats avec et sans cache. Vérifiez également l’envoi des formulaires et la mise à jour des contenus importants. Lorsque vous contactez le fournisseur de services, joignez l’heure de la visite, l’adresse de la requête, l’identifiant du nœud, l’état du cache et l’identifiant de suivi de la requête afin de faciliter la localisation du problème.

Le remplacement du CDN n’est justifié que si les éléments recueillis montrent que le réseau des principaux clients les dirige régulièrement vers des nœuds inadaptés, ou si la qualité des interconnexions locales ne peut pas être améliorée. Si le goulot d’étranglement se situe au niveau des API dynamiques, des règles de cache ou des scripts tiers, corrigez d’abord le problème concerné, puis évaluez si la couverture des nœuds est suffisante.