Si vous divisez l'optimisation des performances de WordPress en trois couches :

  • couche de la station sourceHôte / PHP / Base de données / Extension de cache — Détermine le TTFB et la charge du serveur principal
  • couche de ressourcesOptimisation des images - déterminer la taille et la vitesse de téléchargement de la première grande image
  • couche de distribution: CDN — Décidez de rapprocher les ressources des visiteurs, d’améliorer la stabilité du cache et d’alléger le serveur d’origine

ce document CDN Accélération：

  • Savoir ce que CDN peut résoudre ou non
  • Choisir la formule CDN et le fournisseur qui vous conviennent, et comprendre les limites des versions gratuite et de base
  • Mise en ligne dans un ordre à faible risque, sans planter le site ou avoir un incident avec le cache du commerce électronique/de l'adhésion.
  • Vérifier que “ça marche” et dépanner “pourquoi il n'y a pas de mise à jour, pourquoi il y a un ralentissement, pourquoi il y a des ficelles dans le contenu” lors de la mise en ligne.”

1. Clarifions d’abord les concepts : ce que CDN règle et ne règle pas

1.1 CDN résout principalement 3 problèmes

1.1.1 Livraison plus rapide des ressources statiques
Les ressources statiques telles que les images / CSS / JS / polices / icônes sont plus proches du visiteur, se téléchargent plus rapidement et rendent la page de manière plus cohérente.
Pour WordPress, en particulier les thèmes et les ressources de plugins (wp-content/themes/、wp-content/plugins/) ainsi que les images de la galerie des médias (wp-content/uploads/) est généralement le “gros bonnet”.

1.1.2 Réduction de la pression sur les postes sources
Une fois le cache en périphérie atteint, les requêtes n’auront plus à revenir fréquemment vers l’origine, et la bande passante, les connexions simultanées, les E/S disque et les fluctuations de CPU du serveur d’origine seront allégées.
Cela est particulièrement vrai pour les scénarios de vagues tels que “les pages d'événements, les articles en rafale et les pages de produits qui reçoivent beaucoup de visites”.

1.1.3 Amélioration de la stabilité (plus grande résistance aux fluctuations)
Lorsque le trafic augmente, les nœuds périphériques absorbent un grand nombre de demandes en double, et la station source a beaucoup moins de chances d'être interrompue.
Vous constaterez un “accès plus fluide” : le cache périphérique continue de fonctionner même lorsque le site source est momentanément sollicité.

1.2 Trois types de problèmes que CDN ne résoudra pas automatiquement

1.2.1 Station source lente elle-même
Base de données lente, logique du plugiciel lente, calcul PHP lent — ces éléments relèvent de problèmes au niveau du site d’origine.
CDN peut accélérer les ressources statiques, mais si la page d’accueil HTML est encore générée lentement, les utilisateurs auront quand même l’impression que le site est lent à l’ouverture. Dans ce cas, priorisez l’hébergement, le plugin de cache et l’optimisation de la base de données.

1.2.2 L'image elle-même est trop grande
CDN ne peut pas comme par magie réduire la grande image de 3MB.
Vous devez d'abord optimiser les images : stratégie de dimensionnement (ne téléchargez pas d'images surdimensionnées), compression, WebP/AVIF, stratégie de chargement paresseux, etc.

1.2..3 Scripts tiers lents
Les publicités, les statistiques, le service clientèle, les éléments des médias sociaux, etc. proviennent de domaines tiers.
CDN ne peut généralement pas les rendre plus rapides; vous ne pouvez que réduire ou retarder le chargement, remplacer le fournisseur ou optimiser la stratégie des scripts.

suggestion

Commencez par bien configurer la couche du site source et la couche des ressources, puis faites CDN; l’effet sera plus évident et il y aura moins de problèmes.

2. Choix en 30 s : de quel format de CDN avez-vous besoin?

Pour WordPress, il existe deux catégories principales. Si vous choisissez “Format” puis “Prestataire de services”, l'idée sera très claire.

2.1 Type “ proxy inverse ” intégré (plus simple, convient à la plupart des sites)

**特点：**它不仅是 CDN，还把 DNS / SSL / Protection de sécurité de base (p. ex. DDoS/WAF) Ensemble, ils sont emballés. Vous y accédez et il se place devant votre site comme un proxy.

Ce que vous obtiendrez :

  • Gestion des certificats et de TLS simplifiée
  • Point d’entrée unifié pour la protection de sécurité (protection DDoS de base, contrôle d’accès, WAF, etc.)
  • Mise en cache en périphérie avec moteur de règles (possibilité de mettre en place des politiques de mise en cache plus granulaires, de contourner les politiques)
  • “Plus d'espace pour l'expansion” : si vous souhaitez ajouter plus tard la sécurité, les limites de vitesse et la protection contre les robots, tout cela se trouve généralement dans le même système.

Représentant : Cloudflare / EdgeOne de Tencent Cloud International / ESA d’Alibaba Cloud International

Si vous le souhaitez :

  • Vous le souhaitez. HTTPS + CDN + sécurité de base tout faire en une seule fois
  • Souhaitez-vous unifier la résolution des noms de domaine et la couche proxy sous une seule plateforme ?
  • Vous accordez davantage d’importance à l’expérience globale et à l’évolutivité future, sans vouloir séparer le DNS, les certificats, le CDN et la sécurité en plusieurs ensembles distincts

2.2 Pull “ statique ” pur CDN (faible risque pour commencer, accélère surtout les images/CSS/JS)

**特点：**你只把静态资源放到 CDN 边缘缓存；HTML 页面仍由源站（以及源站缓存插件）负责。

Ce que vous obtiendrez :

  • Risque commercial très faible : pas d“”enchaînement de contenu/carton" si vous ne touchez pas à l'HTML”
  • La modélisation des coûts est plus intuitive : elle est généralement facturée en fonction du trafic, de la demande ou de la région.
  • Une structure plus pure : plus proche d'un “service de distribution de ressources statiques”.”

**代表：**bunny.net（按量计费模型清晰）

Si vous le souhaitez :

  • Vous devez d'abord prendre la “mesure la plus sûre” : l'accélération des ressources statiques.
  • Vous voulez obtenir rapidement des revenus avant de décider si vous voulez ou non utiliser un proxy ou une mise en cache complète du site.
  • Vous voulez que le coût soit plus proche de “payer pour ce que vous utilisez”.”

3. comment faire

  • Niveau 1 : Type d'agent intégré (préféré): Cloudflare / EdgeOne / ESA
  • Niveau 2 : Pull statique CDN (départ prudent): bunny.net / Cloudways CDN, etc.

4. les prestataires de services recommandés

4.1 CloudflareIntégration d'un proxy inversé (démarrage libre, maturité écologique)

Accélération WordPress - HOSTFO

Qu'est-ce que c'est ?
Une fois le nom de domaine connecté, il agit comme proxy devant le site Web et fournit CDN, des certificats, une protection de base ainsi que des capacités de règles de mise en cache.

pour qui

  • Pour avoir l’esprit tranquille : HTTPS + CDN + sécurité de base tout-en-un
  • Vouloir un écosystème mature : suivi de l'ajout d'un WAF, d'une limite de vitesse, de règles de bord, etc.

point de risque

  • Les mises à jour ne prennent pas effet: Après la mise en ligne de CDN, la chaîne de cache s’allonge (cache du navigateur + cache CDN + cache du site d’origine). Il faut une “ stratégie de version ” pour rendre les mises à jour contrôlables (arbre de diagnostic plus loin).
  • Attention à la mise en cache du HTMLsi l'on met en cache du HTML, les pages de commerce électronique, d'adhésion ou de personnalisation doivent être strictement contournées, faute de quoi elles sont sujettes à de graves incidents (voir la liste des scénarios ci-dessous).

instructions：

  • Positionnement : proxy inverse tout-en-un (SSL + CDN + protection de base)
  • Adapté à : l'économie en ligne, un grand espace pour une expansion ultérieure
  • Valeur fondamentale : portail unifié de certificats/sécurité/cache
  • Risques : les mises à jour reposent sur des politiques de gestion des versions ; la mise en cache HTML doit être étroitement contournée.

4.2 Tencent Cloud International EdgeOneIntégration d'un proxy inverse

Accélération WordPress - HOSTFO

Qu'est-ce que c'est ?
Le formulaire est également une plateforme tout-en-un d“”accélération + sécurité + certificats", qui convient à la mise en place de sites dans la gestion de la couche d'agents unifiés.

  • Comme Cloudflare, offre aussi une version gratuite, mais habituellement il y a Quota/plafond fonctionnel(nombre de règles, nombre de tâches de journalisation, etc.), mais il n’est pas nécessaire de modifier DNS; il suffit d’utiliser l’accès par cname.La version gratuite n'est pas recommandée pour les sites web commerciaux！
  • En attendant, les plans gratuits sont souvent synonymes de SLA non garanti
    Cela fonctionne, mais pas en tant que “paquet commercial d'accords de niveau de service”.
  • Si vous souhaitez passer automatiquement d'une ligne de Chine continentale à l'autre en Chine continentale, vous devrez généralement remplir d'abord le formulaire de demande d'informations.Chine ICP Record; seules les routes internationales peuvent être utilisées lorsqu'elles ne sont pas déposées.

Description :

  • Positionnement : intégration d'un proxy inverse (accélération + sécurité + certificats)
  • Idéal pour : ceux qui souhaitent un accès intégré et envisagent une capacité de nœud en Chine continentale
  • Gratuit : il existe des plans et des versions gratuits, mais les quotas sont limités et les accords de niveau de service ne sont généralement pas garantis.
  • Risques : les quotas de règles/logs/sous-domaines doivent être planifiés à l'avance ; la mise en cache de HTML doit être tout aussi prudente.

4.3 Aliyun International ESAIntégration d'un proxy inverse

Accélération WordPress - HOSTFO
  • Comme Cloudflare, offre aussi une version gratuite, mais habituellement il y a Quota/plafond fonctionnel(nombre de règles, nombre de tâches de journalisation, etc.), mais il n’est pas nécessaire de modifier DNS; il suffit d’utiliser l’accès par cname.La version gratuite n'est pas recommandée pour les sites web commerciaux！
  • Créer un compte sur le site international pour utiliser
  • Accédez à la console ESA pour ajouter un site et sélectionnez l'option gratuite Entrée accès à l'abonnement
  • Si vous souhaitez passer automatiquement à la ligne de la Chine continentale en Chine continentale, vous devez généralement commencer par remplir le formulaire ICP ; vous ne pouvez passer à la ligne internationale que si vous n'avez pas rempli le formulaire.
  • La version gratuite est plus adaptée au développement, aux tests et à l'évaluation et n'est généralement pas équivalente aux logiciels commerciaux d'accords de niveau de service.
  • Les offres gratuites sont souvent assorties de limites de vitesse ou de restrictions en matière de méthodes de support (par exemple, accords de niveau de service, etc.).

En ce qui concerne la ligne de la Chine continentale :

  • Pour activer les nœuds en Chine continentale, vous devez généralement remplir les conditions de dépôt et les conditions régionales.
  • Entrée libre Défaut d'itinéraire international, le souhait de prendre l'itinéraire de la Chine continentale doit être complété.Exigences en matière d'enregistrement du PCI de la Chine

Description :

  • Positionnement : intégration d'un proxy inverse (accélération du site + sécurité)
  • Gratuit : compte de station internationale disponible Accès gratuit ; la valeur par défaut ne comprend pas l'accélération de la Chine continentale.
  • Idéal pour : une évaluation/un test avec une utilisation légère ; ou un paquet de mise à niveau ultérieur
  • Risques : limites libres à examiner (accords de niveau de service/limites de vitesse/méthodes d'assistance) ; zones et dépôts à planifier à l'avance

4.4 bunny.net: Pull statique CDN (démarrage à faible risque, facturation à l’usage claire)

Accélération WordPress - HOSTFO

Si vous préférez “ sécuriser d’abord les gains les plus stables ”, un Pull CDN comme bunny convient très bien :
Il s'agit plutôt d'un “service de livraison de ressources” : vous lui donnez des ressources statiques à livrer, le coût est généralement lié au trafic/aux demandes/à la région, et le modèle est clair et contrôlable.

En forme :

  • faire qqch. en premier Images / CSS / JS / Polices Accélération statique de
  • Vous voulez d’abord obtenir des revenus stables et à faible risque, sans vous presser de confier tout le site à une plateforme d’agence intégrée (DNS/SSL/WAF)
  • Vous souhaitez que le modèle de coût soit plus proche de “payer pour ce que vous utilisez” plutôt que d'opter d'emblée pour un progiciel plus complexe.

point de risque

La “ mise à jour ” des ressources statiques qui ne s’applique pas n’est presque jamais un bogue de CDNIl s'agit plutôt d'un comportement normal du système de mise en cache :
Lorsque vous mettez à jour les CSS/JS/images dans le backend, mais que le fichierL'URL de la ressource est inchangée.(Même adresse/nom de fichier/chemin), CDN et le navigateur continueront raisonnablement à utiliser l’ancien cache, donc tu verras “ pourquoi ça n’a pas été mis à jour ”.

Un principe clair et applicable :

Les numéros de version sont prioritaires, les poches de purge.

Pourquoi c'est le plus stable :

  • Changement de numéro de version/nom de fichier → Changement d’URL → CDN traité comme une nouvelle ressource en cache → Nouvelle version presque immédiatement active
  • **La purge** exige que vous la déclenchiez activement, ce qui tend à entraîner une portée imprécise et une propagation retardée des nœuds ; une purge fréquente peut également entraîner des taux de réussite plus faibles, davantage de retours et une plus grande volatilité.

Des exemples faciles à voir :

  • style.css Le contenu a changé, mais l'URL est toujours la même style.css → CDN Continuer avec l’ancien cache (raisonnable)
  • L'URL devient style.css?ver=20260103 或 style.abc123.css → CDN est considéré comme une nouvelle ressource → la nouvelle version prend effet immédiatement

bunny comme pratique exemplaire de “ première étape CDN ”

  1. Ne couvrir d'abord que les ressources statiques(images/CSS/JS/fonts), ne mettez pas le HTML en cache dès le départ !
    • Avantage : il n'y a pratiquement pas d'incidents graves tels que “l'utilisateur voit le contenu ou le numéro de série du panier d'un autre utilisateur”.
    • Vous avez également plus de chances de valider les gains : ressources statiques plus rapides, postes sources plus légers
  2. Une bonne stratégie de mise à jour
    • CSS/JS : essayer d'utiliser le numéro de version/le changement de nom de fichier
    • Images : essayez d'éviter la “couverture du même nom” à long terme, il est davantage recommandé de changer le nom du fichier et le chemin d'accès (en particulier la bannière de la page d'accueil et le plan de l'événement).
  3. Confirmer le résultat à l'aide de la liste de contrôle de validation au moment de la mise en service.
    • Les ressources statiques proviennent-elles de CDN
    • Le taux de réussite augmente-t-il progressivement et la bande passante/les demandes de la source sont-elles plus fluides (voir la liste des vérifications ci-dessous) ?

prendre note

Si votre activité concerne la Chine continentale, ou si vous souhaitez un accès plus rapide à votre site web en Chine continentale.

Aliyun China et Tencent Cloud China valent tous deux la peine d'être choisis, si votre nom de domaine a été déposé ICP en Chine continentale, lorsque vous utilisez EdgeOne ou ESA, l'accès à la Chine continentale basculera automatiquement sur la ligne de la Chine continentale !

“Utilisation des nœuds de la Chine continentale”Généralement, il s'agit d'un dépôt de demande d'aide au titre du PCI.

consultation

“Optimisation de l'expérience d'accès transfrontalier au site web”peut être une autre capacité distincte et n'est généralement pas la même que “libre avec les nœuds de la Chine continentale”".”

5) Feuille de route vers la ligne d'arrivée : progresser en 3 phases (de stable à fort)

La raison la plus fréquente pour laquelle le CDN devient “ le plus facile à mêler ”, c’est qu’on veut activer toutes les capacités au maximum dès le départ.

Étape 1 : seulement les ressources statiques CDN (fortement recommandé de le faire d’abord)

les objectifsImages/CSS/JS/polices via CDN; HTML n’est pas mis en cache dans CDN (ou laissé temporairement inchangé)

Pourquoi est-ce la chose la plus sûre à faire en premier ?

  • Risque minimal : la mise en cache des ressources statiques est erronée, jusqu'à “style/image non mis à jour”, ce qui est gérable.
  • Ne touche pas à l'état de connexion, aux processus de commerce électronique, à l'exactitude des informations sur les comptes.
  • Les avantages sont évidents : les téléchargements de ressources statiques sont plus rapides et les sites sources plus fluides !

Problèmes courants à ce stade (l'arbre de dépannage sera donné plus loin)

  • Contenu mixte (la page charge une ressource HTTP)
  • Les mises à jour des ressources statiques n'ont pas d'effet (les URL ne changent pas).

Étape 2 : Stratégie d'actualisation (numéro de version d'abord, poches de purge/d'échec)

C’est le critère décisif pour savoir si “ CDN ” est réalisé de façon professionnelle ou non.

Une règle stricte :

Ne comptez pas sur la purge pour les mises à jour qui peuvent être résolues par des changements de numéro de version ou de nom de fichier.

Pourquoi les liens de cache deviennent métaphysiques lorsqu'ils sont plus longs :

  • Mise en cache du navigateur : il se peut que d'anciens CSS/JS soient mis en cache localement.
  • Cache CDN : le nœud en périphérie pourrait avoir mis en cache une ancienne ressource
  • Mise en cache du site source : les plugins de mise en cache et les caches du serveur peuvent encore produire d'anciens contenus.

Si vous n'avez pas de stratégie de versionnement, la version devient.. :
“Changé quelque chose → Rafraîchir → Ne fonctionne pas → Vider le cache à nouveau → Ne fonctionne pas à nouveau → Vider un autre niveau de cache”
C’est justement le principal irritant que bien des gens ont avec CDN.

Stade 3 (avancé) : mise en cache ou non du code HTML (rendement élevé mais risque le plus élevé)

La mise en cache HTML (mise en cache sur tout le site/en bordure de site) réduit considérablement le TTFB, mais constitue également un domaine à fort taux d'incidents dans les scénarios WordPress.

En cas d’incertitude, ne mettez pas le HTML en cache. Commencez par CDN statique + un plugin de cache sur le serveur d’origine.

Si vous souhaitez mettre le HTML en cache, deux règles s'appliquent :

  1. Elle ne commence qu'avec l“”État visiteur".Cache uniquement les pages des visiteurs non enregistrés
  2. Rédiger d'abord la liste de contournementL'exactitude vient en premier, puis les résultats

6. liste des règles de scénario : ce qu'il faut faire pour différents types de sites sans incident

6.1 Sites de contenu / blogs (basés sur des articles, nombreux visiteurs)

témoignages

  • Ressources statiques : entièrement mises en cache
  • HTML : envisager la mise en cache de la “page du visiteur non connecté”.”

Il est souvent nécessaire de contourner le

  • Backend & Login :/wp-admin/*、/wp-login.php
  • Avant-première/projet (avant-première)
  • Page de résultats de recherche (les paramètres changent souvent, il est plus économique de ne pas les mettre en cache)
  • Requête POST de soumission de formulaire/commentaire

Les clés de cache doivent au moins faire la distinction entre

  • Si vous êtes connecté ou non (dimension du cookie)
  • Langues (stations multilingues)

6.2 Site de l'entreprise / page d'atterrissage marketing (formulaires, activités à foison)

témoignages

  • Ressources statiques : entièrement mises en cache
  • HTML : les pages d'atterrissage publiques peuvent être mises en cache (état invité), mais attention aux pages de résultats des formulaires.

L'écueil le plus facile à éviter : le suivi des paramètres conduisant à la fragmentation du cache
Les pages d'atterrissage sont courantes utm_* Paramètres :

  • Toutes les clés de cache d'Engage → Cache déchiqueté, faible taux de réussite
  • Ignorer tout → Quelques pages qui dépendent du rendu des paramètres peuvent ne pas être conformes aux attentes.

6.3 Site d'adhésion / site de cours / communauté (forte proportion de personnes connectées)

rendre un verdictLa mise en cache de HTML doit être effectuée avec beaucoup de précautions.
Approche prudente habituelle : CDN statique + cache d’origine/cache d’objets; HTML mis en cache seulement pour les visiteurs

Doit contourner

  • Connexion/enregistrement/récupération du mot de passe
  • Centre de comptes, Commandes/abonnements, Détails personnels
  • Toutes les pages et interfaces “fortement liées à l'état de l'utilisateur”.

6.4 Station de commerce électronique (WooCommerce)

Liste des principales voies de contournement

  • Panier d'achat, caisse, page de compte
  • Confirmation de commande, pages relatives au rappel de paiement
  • Connexion/enregistrement, coupon/points et autres entrées liées à l'état de l'utilisateur

Pourquoi le commerce électronique est-il plus sujet aux accidents ?

  • Une fois que l'utilisateur dispose d'un panier d'achat, d'une session et d'un état de connexion, la page est hautement personnalisée.
  • Les conséquences typiques d'une mise en cache HTML qui n'est pas contournée/différenciée sont les suivantes : inadéquation du panier d'achat, chaînes de compte et anomalies dans l'affichage des prix.
    L'exactitude est prioritaire, ne sacrifiez pas l'exactitude au profit du succès.

6.5 Sites multilingues / multidevises

témoignages

  • Ressources statiques : entièrement mises en cache
  • HTML : l'état de l'invité peut être mis en cache, mais les clés de cache doivent clairement distinguer les variantes de langue/devise.

La clé de cache doit être prise en compte

  • Langue (chemin) /en/ /zh/ ou un sous-domaine en.）
  • Si vous êtes connecté ou non (cookie)
  • Taux de change/d'imposition (si cela affecte la présentation)

7. alertes aux risques

Risque 1 : Mise en cache du mauvais contenu (le plus grave)

  • Erreur de mise en cache des ressources statiques : principalement de vieux styles/images
  • Erreur de mise en cache HTML : may string content, string shopping cart, string account - il s'agit d'un incident grave !

Risque 2 : Les mises à jour ne prennent pas effet (le plus fréquent)

Au fur et à mesure que le lien de cache s'allonge, la mention “les modifications ne prennent pas effet” sera de plus en plus fréquente :

  • Les changements de numéro de version/nom de fichier sont prioritaires.
  • Purge / pédalage d'échec
  • Le processus de publication doit être reproductible (savoir quelles URL ont été modifiées pour chaque publication).

Risque 3 : Limite de l'engagement pour la version gratuite/la version de démarrage

  • Caractéristiques communes des programmes gratuits : quota limité, exclusion de certaines capacités, approche SLA/support non équivalente à une utilisation commerciale complète.

Risque 4 : Les compétences liées à la Chine continentale sont facilement mal interprétées

  • ASE : l'enregistrement du PCI chinois est requis pour les itinéraires à destination de la Chine continentale
  • EdgeOne : Le dépôt d'un PIC en Chine est nécessaire pour les liaisons avec la Chine continentale

8 Liste de contrôle de validation : comment confirmer qu'il “fonctionne vraiment” après sa mise en service”

8.1 Les ressources statiques passent-elles vraiment par CDN?

  • Images/CSS/JS proviennent-ils du domaine/nœud périphérique CDN
  • Si vous pouvez ou non voir des signes clairs d'accès au cache (les signes varient en fonction de la plate-forme).

8.2 La pression du poste source a-t-elle baissé ?

  • La bande passante de la station source est-elle plus fluide ?
  • si le nombre de demandes/connexions en provenance du site source a diminué (en particulier les demandes de ressources en double)

8.3 Les mises à jour sont-elles gérables ?

  • Modifier les CSS/JS une fois ou remplacer une image.
  • Si la nouvelle version peut être accélérée par “changement de numéro de version/changement de nom de fichier”.
  • Si vous ne pouvez mettre à jour que par purge, vous n'avez pas mis en place une bonne stratégie de gestion des versions (donnez la priorité à la stratégie de correction, ne faites pas de la purge une routine quotidienne).

8.4 Les pages clés dynamiques sont-elles correctes ?

(E-commerce/site d'adhésion indispensable)

  • Le contenu de la page après la connexion/la déconnexion est correct.
  • Les pages relatives au panier, à la caisse et au compte sont toujours correctes.
  • Il n'y a pas d'exception “différents utilisateurs voient le même contenu d'état utilisateur” (risque élevé).

8.5 Le taux d'erreur a-t-il augmenté ?

  • Délai de retour à la source, 5xx, échec intermittent de l'ouverture
  • Il s'agit généralement d'un support insuffisant à la source, de règles incorrectes, de déclenchements de limites de vitesse ou de problèmes au niveau du lien vers la source.

9. mise à jour de l'arbre de non-fonctionnalité (transformer la “métaphysique” en étapes)

Commencez par déterminer le type de problème que vous rencontrez :

9.1 Ressources statiques non mises à jour (CSS/JS/images toujours anciennes)

Scénario A : vous êtes le seul à voir l'ancien dispositif, le dispositif furtif/échangé est le nouveau.
Suspicion de priorité : mise en cache du navigateur

  • Piste de résolution : publier de nouvelles ressources en modifiant le numéro de version/le nom de fichier.

Scénario B : Tout le monde voit l'ancien (les dispositifs furtifs/différents sont également anciens)
Priorité de suspicion : CDN atteint encore l’ancien cache

  • 99% Cause : L'URL de la ressource n'a pas changé
  • Solutions prioritaires : stratégies de versionnement
  • Poche : Purge (moyens temporaires)

Scénario C : l'ancienne image continue d'apparaître après l'écrasement d'une image portant le même nom.
Problème classique de superposition entre le cache du navigateur et le cache CDN

  • Conseil pratique : essayez d'éviter les “écrasements du même nom” à long terme, utilisez de nouveaux noms de fichiers/chemins d'accès ou des numéros de version.

9.2 Le code HTML n'est pas mis à jour (le contenu de la page/module est toujours ancien)

Scénario A : le backend/login est nouveau, les visiteurs voient l'ancien.
Suspicion de priorité : le code HTML de l'invité est mis en cache

  • Tout d'abord : ces pages doivent-elles avoir un cache HTML ?
  • S'il doit être mis en cache : nécessité d'une stratégie de rafraîchissement contrôlée, sinon la libération est incontrôlable.

Scénario B : Seules certaines régions/certains réseaux renvoient les anciens contenus
Doute sur la priorité : les différents nœuds de bordure ont des états de cache différents.

  • Orientation de la résolution : faire converger les différences à l'aide d'une stratégie de version/réactualisation ; procéder à une invalidation plus explicite si nécessaire.

Scénario C : Anomalies dans les utilisateurs connectés/les paniers d'achat
Signe de risque élevé : le contenu mis en cache n'est peut-être pas le bon

  • Vérifier immédiatement si les pages relatives à l'état de l'utilisateur (panier/caisse/compte, etc.) sont mises en cache.
  • Vérifier si la clé de cache ignore les variantes de clés telles que “userland cookie/language/currency”.

10. recommandations

Cloudflare

  • Intégration d'un proxy inverse
  • Adapté à : démarrage de l'épargne
  • Focus : politique de versionnement pour traiter les mises à jour ; mise en cache du HTML à partir de l'état de l'invité
  • Risque : les pages dynamiques doivent être contournées

Tencent Cloud International EdgeOne

  • Intégration d'un proxy inverse
  • Adapté : tenir compte de la capacité des nœuds de la Chine continentale et de l'accès intégré
  • Gratuit : il existe des plans et des versions gratuits, mais les limites des quotas et des engagements doivent être clairement définies.
  • Risques : quotas de règles/logs/sous-domaines à prévoir ; mise en cache de HTML avec prudence

Aliyun International ESA

  • Intégration d'un proxy inverse
  • Gratuit : Comptes internationaux disponibles Entrée Free Access
  • Risque : limites libres (SLA/support/limite de vitesse) et zones/conditions de dépôt à confirmer à l'avance.
  • Convient pour : évaluation/test et accès léger ; ou mise à niveau ultérieure du paquet, ou prise en compte de la capacité du nœud de la Chine continentale et accès intégré.

bunny.net

  • Statique Pull CDN
  • Adapté : accélération statique à faible risque d'abord
  • Focus : numéro de version d'abord, Purge undercover ; éviter les substitutions de noms identiques
  • Risque : rencontres fréquentes avec d“”anciennes ressources" si la stratégie de mise à jour n'est pas appliquée correctement.”

11. les recommandations d'action

  1. Choisissez d’abord le type : proxy inverse intégré (Cloudflare/EdgeOne/ESA) ou Pull statique CDN (bunny)
  2. Vivre en direct par étape :D'abord statique → ensuite politique de versionnement → enfin envisager la mise en cache HTML
  3. Vérification par la liste de contrôle de validation après la mise en service : succès/retour à la source/mise à jour/ contournement dynamique/taux d'erreur.
  4. Pour aller plus vite : retournez dans “Cache Plugin” “Image Optimisation” et compressez à nouveau les couches source et ressource !

FAQ WordPress CDN

1. Pourquoi est-ce encore lent après avoir utilisé CDN?

La raison la plus fréquente n’est pas que CDN ne sert à rien, mais que le goulot d’étranglement ne se trouve pas au niveau de la “ couche de livraison ”.

Vous pouvez les juger dans cet ordre :

  • La TTFB reste élevée.Explication de la lenteur de la génération HTML à partir de la source (base de données/plugin/cache, configuration du plugin/performance de l'hébergement) → retour à l'optimisation au niveau de la source
  • La première image d'ensemble est très lenteindique une taille, des dimensions ou un format d'image incorrects → optimiser d'abord l'image (compression, WebP/AVIF, stratégie de dimensionnement)
  • Les scripts tiers ralentissentLes scripts pub/statistiques/service client ne sont généralement pas aidés par CDN; il faut réduire ou retarder leur chargement
  • Seules certaines zones sont lentes: il peut s'agir d'un écrasement de nœud, d'une ligne de retour ou d'un oubli de cache (faible taux de réussite) → examiner le taux de réussite et les retours

CDN est chargé de livrer plus rapidement les “ ressources déjà optimisées ”; un serveur d’origine lent, de grosses images et des scripts lents doivent être traités séparément.

2) Pourquoi les utilisateurs voient-ils toujours l'ancienne version alors que j'ai mis à jour les CSS/JS/images ?

Il s’agit du problème le plus courant dans le scénario CDN, et la cause principale est généralement :L'URL de la ressource est inchangée.le système de mise en cache continuera raisonnablement à utiliser l'ancien cache.

Le principe du traitement le plus stable :

  • numéro de version priorité: Laisser l'URL de la ressource changer (par ex. style.css?ver=xxxx ou le hachage du nom de fichier)
  • Purge UnderwritingLa version du cache : L'effacement du cache est un palliatif lorsque vous n'avez pas mis en place de politique de versionnement.

Si vous remplacez souvent la bannière de la page d'accueil / l'image de la campagne, il est recommandé d'éviter “l'écrasement du même nom” et de préférer l'utilisation du nouveau nom de fichier / du nouveau chemin d'accès (plus facile à contrôler).

3) Dois-je mettre le HTML en cache ? N'y a-t-il aucun intérêt à ne pas le mettre en cache ?

Pas nécessairement nécessaire.

Pour de nombreux sites, la plus grande valeur de CDN vient de :

  • Plus rapide pour les ressources statiques (images/CSS/JS/fonts)
  • Réduction de la pression du poste source et amélioration de la stabilité

Mise en cache du HTML Les avantages peuvent en effet être plus importants (la TTFB serait plus faible), mais les risques sont également plus grands : le commerce électronique, les adhésions, le contenu personnalisé, le multilinguisme et le multidevise sont tous susceptibles de mettre en cache un contenu erroné.

Route régulière :

  1. Commencer par une version statique CDN (faible risque, rendement élevé)
  2. Passer en revue la politique de versionnement et la liste de contrôle de validation
  3. Réévaluer s'il faut mettre en cache le code HTML (en commençant par “guest state”)

4. Le site de commerce électronique peut-il utiliser CDN ? Est-ce que ça va perturber le panier ?

Il peut être activé, et devrait l'être (au moins pour les ressources statiques), mais évitez de mettre en cache les pages du userland.

  • Les ressources statiques peuvent être mises en cache: images, CSS, JS
  • La page du userland doit contourner leHTML : Ne pas mettre en cache les pages relatives au panier d'achat, à la caisse et au compte HTML
  • Tant que vous ne mettez pas ces pages en cache HTML, le risque de “diaphonie” est fortement réduit !

Comment créer un site multilingue et multidevise CDN sans mélanger les langues ni les prix?

centre Clé de cache Est-ce exact ?

  • Langue (chemin ou sous-domaine)
  • Devise (si elle affecte l'affichage du prix)
  • Si vous êtes connecté ou non (cookie)
  • Région/taux d'imposition (si la page est susceptible d'être modifiée par région)

Si ces dimensions ne sont pas prises en compte dans la logique de mise en cache, il est facile d'obtenir que les utilisateurs de la langue A voient le contenu de la langue B ou que les prix soient incohérents.

6. Dois-je choisir le proxy inverse intégré (Cloudflare/EdgeOne/ESA) ou le Pull statique CDN (bunny)?

Vous pouvez faire votre choix en fonction de la “cible” et de la “préférence pour le risque” :

  • Tout régler d’un coup HTTPS + CDN + sécurité de base, avec possibilité d’étendre les règles/WAF par la suiteIntégration d'un proxy inverse
  • Vous souhaitez effectuer la première étape de la première étape la plus stable (les ressources statiques sont plus rapides) et vous ne voulez pas déplacer l'ensemble de l'agent :Statique Pull CDN(par exemple, lapin)

En cas d'hésitation, un conseil par défaut s'impose :D’abord statique CDN → Exécuter la politique de gestion des versions et la liste de contrôle de la validation → décider ensuite s'il convient d'utiliser le proxy/cache HTML.

7) La version gratuite peut-elle être utilisée directement sur le site officiel ?

Il peut être utilisé, mais pensez à “gratuit” comme “démarrage/évaluation/utilisation légère”, et non comme “programme formel avec des accords commerciaux de niveau de service”.

  • Vous sentez-vous à l'aise avec un programme gratuit dePlafonnement des quotas, fonctionnalités manquantes, différences d'assistance et absence éventuelle d'engagements en matière d'accords de niveau de service (SLA).？
  • Si ce n'est pas le cas, vous devez considérer la version gratuite comme un essai et passer ensuite à une version plus adaptée.

8. Comment puis-je confirmer que CDN fonctionne vraiment, et que ce n’est pas juste un effet placebo ?

Confirmez avec ces trois étapes (sans outils compliqués) :

  1. Vérifier si les ressources statiques sont renvoyées depuis CDN(si la source de l'image/CSS/JS a changé)
  2. Voir si le taux de réussite et la source de rendement s'améliorent(Frappez vers le haut, sourcez vers le bas pour obtenir des gains réels)
  3. Modifier une fois la stratégie de mise à jour de la validation CSS/image(numéro de version en vigueur, indiquant la contrôlabilité de la liaison)

Si vous ne pouvez pas faire #3, plus vous optimisez, plus vous risquez d'être tourmenté par “les mises à jour ne prennent pas effet”, il est donc recommandé de donner la priorité à la politique de gestion des versions.

9) Pourquoi suis-je souvent bloqué lorsque j'active l'accélération pour la Chine continentale ?

La cause la plus fréquente est :Inadéquation entre les choix régionaux et les conditions de dépôt。

  • Si vous souhaitez sélectionner une région d'accélération qui inclut la Chine continentale, vous devrez généralement compléter le formulaire de demande d'autorisation de mise en service. ICP 备案Les sans-papiers ne peuvent sélectionner que des régions n'incluant pas la Chine continentale.

10. Dois-je d’abord installer le plugiciel de cache ou d’abord passer au CDN?

L'ordre général recommandé est le suivant :

  1. Couche du site source : le plugin de cache/la base d'hébergement s'est stabilisé en premier (TTFB en baisse, pression du backend en baisse).
  2. Couche de ressources : optimisation de l'image pour en réduire la taille
  3. Couche de livraison : CDN livrez les ressources plus vite et de façon plus fiable

Si vous ne voulez faire qu'une seule chose en ce moment et que vous avez peur d'un retournement de situation :D’abord statique CDN (phase 1)avec des rendements stables et un risque minimal.