Après avoir activé l’accélération CDN, pourquoi le site reste-t-il lent ? Que faut-il vérifier en premier ?

Après l’activation de l’accélération CDN, les utilisateurs signalent encore que « la page d’accueil s’ouvre lentement », « les images produit mettent très longtemps à apparaître » ou que « le back-office expire parfois ». De nombreux responsables de maintenance soupçonnent immédiatement une couverture insuffisante des nœuds ou de mauvaises performances du fournisseur CDN. En réalité, lors du diagnostic, le CDN ne fait souvent que rapprocher la livraison des ressources statiques ; il ne peut pas corriger automatiquement les lenteurs du programme du serveur d’origine, l’inefficacité des règles de cache, les détours de résolution de nom de domaine ou les scripts tiers qui ralentissent le premier affichage.

Cela est particulièrement vrai pour les sites multilingues destinés aux marchés étrangers, les sites B2B de génération de demandes et les boutiques transfrontalières, dont les visiteurs sont répartis entre l’Amérique du Nord, l’Europe, l’Asie du Sud-Est et d’autres régions. Qu’une même page fonctionne correctement lors d’un test à Pékin ne signifie pas qu’elle sera également rapide sur un réseau mobile américain. Lors de la maintenance après-vente, décomposer d’abord la « lenteur du site » en maillons vérifiables est généralement plus efficace que de changer sans cesse de forfait CDN.

Commencez par identifier où se situe la lenteur : une page lente ne signifie pas forcément un CDN lent

Il est recommandé de conserver un graphique en cascade du navigateur issu d’une visite réelle et de se concentrer sur trois moments : la requête DNS, le délai avant réception du premier octet (TTFB) et le temps de téléchargement des principales ressources. Si le document HTML lui-même attend longtemps, alors que les images, CSS et JS suivants se téléchargent normalement, le problème se situe probablement au niveau du serveur d’origine, de l’application ou de la base de données, et non des nœuds périphériques. À l’inverse, si le document revient rapidement mais que les grandes images, polices ou scripts attendent en file pour être téléchargés, il faut alors examiner en priorité la stratégie de cache, la taille des ressources et le chargement concurrent.

Une erreur d’interprétation fréquente consiste à voir le statut « CDN intégré » et à supposer que tout le contenu est accéléré. En pratique, les interfaces dynamiques, les liens d’images avec paramètres, les chemins du back-office et certains fichiers téléchargeables peuvent revenir au serveur d’origine en raison des règles configurées. Les responsables de maintenance doivent vérifier directement l’état du cache dans les en-têtes de réponse, par exemple les indicateurs de cache atteint, non atteint ou contourné ; les champs varient selon les fournisseurs, mais l’essentiel est de confirmer si la requête est réellement traitée par un nœud périphérique ou si elle retourne au serveur d’origine à chaque fois.

La réponse du serveur d’origine est la première priorité, ne vous laissez pas tromper par « intégré »

La lenteur du serveur d’origine se manifeste généralement de plusieurs façons : le TTFB augmente sensiblement aux heures de pointe ; la première visite d’une même page est lente et le rafraîchissement est légèrement plus rapide ; après la publication de contenu dans le back-office, le front-office expire fréquemment pendant un court laps de temps ; les requêtes d’interface restent longtemps en attente. Cela peut être dû à une saturation du CPU, de la mémoire ou du nombre de connexions du serveur, mais aussi à des retards causés par des plug-ins CMS, des requêtes de modèles, des interfaces de recherche ou des index de base de données mal conçus.

Pour les sites marketing, la page d’accueil est souvent plus susceptible de poser problème que les pages internes. Carrousels, produits recommandés, validation de formulaires, outils de fenêtres contextuelles et codes statistiques y sont tous concentrés ; si chaque visite lit en temps réel plusieurs modules de base de données, le temps d’affichage du premier écran ne sera toujours pas idéal, même si tous les CSS et images sont servis depuis le CDN. Il faut alors chercher des preuves dans les journaux du serveur d’origine, le suivi des performances applicatives ou les requêtes lentes de la base de données, plutôt que d’élargir d’abord le périmètre du cache.

Le « cache forcé sur l’ensemble du site » doit être traité avec une prudence particulière. Les prix des produits, les stocks, l’état de connexion, le panier et les jetons de formulaires de demande ne peuvent généralement pas être simplement mis en cache comme des pages statiques. Une approche plus fiable consiste à distinguer les pages publiques, les interfaces dynamiques et les chemins du back-office : définir une durée de cache raisonnable pour les contenus publics qui changent peu fréquemment ; contourner explicitement le cache pour les interfaces personnalisées ; utiliser des numéros de version ou un mécanisme de rafraîchissement actif pour les pages pouvant être mises en cache, afin d’éviter que les utilisateurs continuent de voir de l’ancien contenu après une mise à jour.

Un faible taux d’utilisation du cache provient souvent de problèmes de règles et de gestion des ressources

Les noms de fichiers des ressources statiques de nombreux sites restent longtemps inchangés : même après la mise à jour d’une image de bannière, elle s’appelle toujours banner.jpg. Pour éviter que les utilisateurs ne voient l’ancienne image, les responsables de maintenance n’ont alors d’autre choix que de définir une durée de cache très courte. Bien que pratique, cette approche entraîne une invalidation fréquente du cache CDN. Une méthode plus appropriée consiste à ajouter des paramètres de version aux ressources mises à jour ou à utiliser des noms de fichiers avec empreinte de contenu, afin que les navigateurs et les nœuds périphériques puissent mettre en cache les anciennes versions en toute confiance, tandis que les nouvelles versions prennent effet rapidement.

Un autre point souvent négligé concerne les paramètres de requête. Certains systèmes ajoutent automatiquement aux images et scripts des horodatages, des paramètres de langue ou des paramètres de suivi. Si le CDN considère chaque combinaison de paramètres comme une nouvelle URL, le cache sera fortement fragmenté ; mais ignorer brutalement tous les paramètres peut affecter le filtrage des produits, le traitement des images ou les contrôles de sécurité. Lors du diagnostic, il convient de répertorier les paramètres les plus fréquents dans les requêtes réelles, puis de définir des règles de conservation, d’ignorance ou de normalisation selon le type de ressource.

Pour les images, il ne suffit pas non plus de « les placer sur le CDN ». Des images produit originales non compressées, des vidéos en lecture automatique sur le premier écran ou le chargement simultané de dizaines d’images de pages de détail occupent tous la bande passante et le thread principal. Pour les images de présentation, il est possible de fournir des dimensions adaptées à l’appareil ; les images situées au-delà du premier écran peuvent être chargées de manière différée ; pour les vidéos, il est préférable d’utiliser une image de couverture et de déclencher la lecture par l’utilisateur. Le compromis est très concret : l’équipe visuelle souhaite de la netteté, l’équipe marketing souhaite des informations complètes, et l’équipe de maintenance doit proposer une taille de fichier et un ordre de chargement acceptables, plutôt que de compresser systématiquement jusqu’à dégrader la qualité.

La résolution DNS et la configuration du nom de domaine constituent souvent des pièges cachés pour les accès interrégionaux

Même avec un grand nombre de nœuds CDN, il faut avant tout que les utilisateurs soient correctement dirigés vers eux. Un CNAME de domaine non entièrement propagé, des enregistrements DNS conflictuels, le maintien simultané d’un enregistrement A et d’un enregistrement CDN, ou une configuration IPv6 incohérente peuvent tous amener certains utilisateurs à contourner le CDN et à se connecter directement au serveur d’origine. Le phénomène le plus typique est le suivant : certaines régions sont très rapides, tandis que d’autres restent continuellement lentes ; le réseau du bureau fonctionne normalement, mais le réseau mobile des clients échoue souvent.

Lors de la maintenance, ne tirez pas de conclusion sur la base d’une seule résolution locale. Il faut observer le résultat final de la résolution du nom de domaine depuis l’environnement réseau du marché cible, et vérifier séparément www, le domaine nu, le sous-domaine mobile, le domaine des images et le domaine des téléchargements. La chaîne de certificats HTTPS et le nombre de redirections doivent également être vérifiés. Une page qui passe de http à https, puis du domaine nu à www, avant de rediriger vers un répertoire de langue, fait déjà subir plusieurs allers-retours à l’utilisateur avant qu’il n’obtienne réellement le contenu.

Si le site sert à la fois les utilisateurs de Chine continentale et ceux à l’étranger, il convient également de vérifier l’état du déploiement et de la conformité. Pour les sites destinés à un accès depuis la Chine continentale, les informations d’enregistrement ICP doivent rester cohérentes avec la configuration réelle des services lors de l’intégration, de la migration de serveur ou du changement d’entité. Pour les procédures telles qu’un nouvel enregistrement ICP, une modification ou un transfert d’accès, vous pouvez vérifier à l’avance les documents et l’enchaînement du processus via le numéro de service d’enregistrement ICP national, afin d’éviter que la fenêtre de mise en ligne ne soit retardée en raison d’incohérences entre le nom de domaine, l’entité ou les informations d’accès.

Les ressources tierces qui ralentissent le premier écran sont un problème fréquent des sites marketing

Les pixels publicitaires, chats en ligne, cartes, codes de vérification, intégrations de réseaux sociaux, analyses comportementales et outils de test A/B ne sont généralement pas sous le contrôle du CDN du site. Un script externe qui répond lentement peut bloquer le rendu ultérieur ; le chargement répété de plusieurs gestionnaires de balises amplifie le problème. Si le domaine d’une requête lente n’appartient pas au site, toute la responsabilité ne doit pas être attribuée à la configuration CDN.

Le principe de traitement est de conserver les scripts qui participent réellement à l’acquisition de prospects et à l’attribution, et de supprimer les codes hérités. Les outils qui n’affectent pas l’affichage du premier écran peuvent être chargés plus tard ; pour les services tiers dont l’accès est limité selon les régions ou qui échouent occasionnellement, il faut prévoir une solution de repli. Les sites de commerce extérieur doivent notamment éviter de reproduire tels quels sur les sites étrangers les composants couramment utilisés en Chine : le parcours d’accès des utilisateurs étrangers est plus long, et toute attente externe peut directement affecter leur patience avant la soumission d’un formulaire.

Suivez le même ordre de diagnostic pour éviter les modifications inefficaces

Dans le traitement réel des tickets, il est possible de procéder dans l’ordre « document de page — état du cache — routage DNS — cascade des ressources — journaux du serveur d’origine ». Vérifiez d’abord si le HTML est lent, puis déterminez si les ressources statiques sont servies depuis le cache ; après avoir confirmé que l’accès entre réellement dans le CDN, revenez examiner l’application, la base de données et les services tiers. Après chaque modification, un nouveau test doit être effectué dans la même région et dans les mêmes conditions réseau, faute de quoi les fluctuations réseau risquent facilement d’être prises pour des effets d’optimisation.

Dans le cadre de ses services à long terme pour les sites multilingues, les boutiques transfrontalières et les scénarios de promotion à l’étranger, Yiyingbao considère généralement les performances du site, les pages de destination publicitaires, l’indexation et l’exploration, ainsi que la conversion des formulaires comme une même chaîne. Le CDN n’en est qu’un maillon, et non un correctif universel. Ce qui mérite vraiment d’être résolu en priorité est le goulot d’étranglement pouvant être démontré par les journaux, les en-têtes de réponse et les parcours d’accès réels ; une fois ce point identifié, les ajustements ultérieurs du serveur d’origine, des règles de cache ou de la stratégie de ressources ne nécessiteront plus de reprises répétées.