Site web CDN Optimisation accélérée

Si l’on divise l’optimisation des performances de WordPress en trois couches :

• couche de la station source: Hébergement / PHP / Bases de données / Plugins de mise en cache - Décider du TTFB et des pressions du backend
• Niveau de ressource: Optimisation des images — détermine le poids au téléchargement et la vitesse de la grande image au premier écran
• couche de distribution: : CDN -- Décider des ressources plus proches des visiteurs, des résultats plus cohérents, des stations sources plus faciles.

ce document CDN Accélération：

• Savoir ce que le CDN fait et ne fait pas
• Sélectionnez le formulaire CDN et le prestataire de services qui vous conviennent (et comprenez la limite entre la version gratuite et la version de démarrage).
• 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” au moment de la mise en ligne, et résoudre les problèmes “pourquoi ça ne se met pas à jour, pourquoi ça ralentit, pourquoi ça fait des chaînes dans le contenu”.”

1) Mettons les choses au clair : ce que fait le CDN et ce qu'il ne fait pas.

1.1 CDN aborde 3 points principaux

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 plus “volumineux”.

1.1.2 Réduction de la pression sur les postes sources
Après avoir atteint le cache périphérique, les requêtes ne sont plus renvoyées à la source aussi souvent, et la bande passante, les connexions simultanées, l'IO du disque et les fluctuations CPU à la source sont plus légères.
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 3 types de problèmes que CDN ne résout pas automatiquement

1.2.1 Station source lente elle-même
Des bases de données lentes, une logique de plugin lente, des calculs PHP lents - ce sont des problèmes au niveau du site source.
CDN peut accélérer les ressources statiques, mais si la génération du HTML de la page d’accueil reste lente, l’utilisateur aura quand même l’impression que “ l’ouverture est lente ”. Dans ce cas, priorisez plutôt : hébergement / extension de cache / optimisation de la base de données.

1.2.2 L'image elle-même est trop grande
CDN ne peut pas “magiquement” rendre plus petite l'image globale 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 aider à être “plus rapides”, vous ne pouvez y remédier qu'en réduisant/retardant le chargement, en remplaçant les fournisseurs ou en optimisant la politique des scripts.

2. Choisir en 30 secondes : de quel format de CDN avez-vous besoin ?

Pour WordPress, il existe deux grandes catégories. Choisissez d’abord la “ formule ”, puis le “ prestataire ”, et tout sera beaucoup plus clair.

2.1 一体化“反向代理型”（更省心，适合多数站点）

**特点：**它不仅是 CDN，还把 DNS / SSL / Protection de base (par 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 :

• HTTPS Gestion simplifiée des certificats et de TLS
• Point d’entrée unifié pour la protection de sécurité (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 international de Tencent Cloud / ESA international d’Alibaba Cloud

Si vous le souhaitez :

• Vous le souhaitez. HTTPS + CDN + Sécurité de base Terminer en une fois
• Souhaitez-vous unifier la résolution des noms de domaine et la couche proxy sous une seule plateforme ?
• Vous êtes plus intéressé par “l'expérience globale et l'expansion ultérieure” et ne voulez pas diviser DNS, certificats, CDN, sécurité en plusieurs ensembles.

---

2.2 “Static Pull CDN” pur (démarrage à faible risque, principalement accélération des 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”.”

Exemple : bunny.net (modèle de facturation à l'usage clair)

Si vous le souhaitez :

• Vous voulez d’abord faire “ l’étape la plus sûre ” — l’accélération des ressources statiques
• Vous souhaitez obtenir rapidement des gains, puis décider ensuite si vous activez le cache proxy / cache du site entier
• Vous souhaitez que le coût se rapproche davantage du “ payez selon votre utilisation ”

3. Comment faire

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

4. Prestataires recommandés

4.1 CloudflareIntégration d'un proxy inversé (démarrage libre, écologiquement mûr)

Qu'est-ce que c'est ?
Vous branchez le domaine et il se place devant le site en tant que proxy, fournissant CDN, des certificats, une protection de base et des capacités de règles de mise en cache.

pour qui

• Pour plus de tranquillité : 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.

Points de risque

• La mise à jour ne prend pas effet: Après la mise en ligne de CDN, la chaîne de cache s’allonge (cache du navigateur + cache CDN + cache du serveur d’origine). Une “ stratégie de version ” est nécessaire pour maîtriser les mises à jour (arbre de diagnostic plus loin).
• Mise en cache du HTML à utiliser avec prudenceSi le HTML est mis en cache, les pages e-commerce, membres ou personnalisées doivent impérativement l’éviter, sinon de graves incidents peuvent survenir (liste des cas plus bas)

instructions：

• Positionnement : solution intégrée de proxy inverse (SSL + CDN + protection de base)
• Convient pour : une mise en ligne en toute tranquillité et une grande marge d’évolution par la suite
• Valeurs clés : point d’entrée unifié pour certificats/sécurité/cache
• Risque : les mises à jour dépendent de la stratégie de version ; le cache HTML doit être strictement contourné

---

4.2 Tencent Cloud International EdgeOne: Intégration du proxy inverse

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, il existe une version gratuite, mais il y a généralement 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’effectuer l’intégration via cname.Version gratuite non recommandée pour les sites web commerciaux！
• Le plan gratuit signifie souvent aussi SLA non garanti
  Ça peut servir, mais ne le considérez pas comme une “ offre SLA commerciale ”.

• Si vous souhaitez basculer automatiquement sur la ligne de Chine continentale en Chine continentale, il faut généralement d’abord terminerEnregistrement ICP chinois; tant qu’il n’est pas enregistré, seule la ligne internationale peut être utilisée.

Description :

• Positionnement : solution tout-en-un de proxy inverse (accélération + sécurité + certificats)
• Convient à : ceux qui souhaitent une intégration unifiée et envisagent des capacités de nœuds 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 ESA: Intégration du proxy inverse

• Comme Cloudflare, il existe une version gratuite, mais il y a généralement 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’effectuer l’intégration via cname.Version gratuite non recommandée pour les sites web commerciaux！
• Créez un compte sur le site international pour l’utiliser
• Accédez à la console ESA pour ajouter un site et sélectionner la version gratuite Entrée Connexion au forfait
• Si vous souhaitez basculer automatiquement vers une ligne en Chine continentale, il faut généralement d’abord effectuer l’enregistrement ICP ; sans cet enregistrement, seules les lignes internationales peuvent être utilisées.
• La version gratuite convient davantage au développement, aux tests et à l’évaluation, et n’équivaut généralement pas à une offre SLA commerciale
• 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.).

À propos des lignes en 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 gratuite par défaut via la ligne internationale, pour utiliser la ligne de Chine continentale, il faut terminerExigences d’enregistrement ICP en Chine

Description :

• Positionnement : plateforme tout-en-un de proxy inverse (accélération du site + sécurité)
• Gratuit : disponible pour les comptes du site international, avec accès gratuit à Entrance ; n’inclut pas par défaut l’accélération en Chine continentale
• Idéal pour : évaluation/test avec utilisation légère ; ou mise à niveau ultérieure
• 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, tarification claire à l’usage)

Si vous voulez “obtenir d'abord les gains les plus sûrs”, un Pull CDN comme le lapin est un bon choix :
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
• Vous voulez d'abord obtenir des “revenus stables et à faible risque” et ne vous précipitez pas pour confier l'ensemble du site à une plate-forme de type proxy (DNS/SSL/WAF tout-en-un).
• Vous souhaitez un modèle tarifaire plus proche du paiement à l’usage, plutôt qu’un système de forfaits plus complexe dès le départ

Points de risque

La “ mise à jour ” des ressources statiques ne prend presque jamais effet à cause d’un bug de CDNmais constitue un fonctionnement normal du système de cache :
Lorsque vous avez mis à jour le CSS/JS/les images dans l’administration, maisL’URL de la ressource n’a pas changé(Même adresse/nom de fichier/chemin), CDN et le navigateur continueront logiquement à utiliser l’ancien cache, et vous verrez donc “ pourquoi ça n’a pas été mis à jour ”.

Un principe clair et applicable :

Priorité au numéro de version, Purge en secours.

Pourquoi est-ce le plus fiable ?

• Changements de version/nom de fichier → Changement d’URL → CDN traité comme une nouvelle ressource en cache → Nouvelle version quasi immédiate
• Le Purge (vider le cache) doit être déclenché manuellement ; le périmètre est facilement imprécis et la propagation entre nœuds a un délai ; des Purge fréquents font aussi baisser le taux de cache hit, augmentent les retours à l’origine et amplifient les fluctuations

Exemple facile à comprendre :

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

bunny comme meilleure pratique pour “ première étape CDN ”

1. Couvrir d’abord uniquement les ressources statiques(images/CSS/JS/polices), ne mettez pas le HTML en cache d’emblée
   • Avantage : quasi aucun risque que des utilisateurs voient le contenu d’autres personnes ou qu’il y ait un mélange de paniers
   • Il vous est également plus facile de vérifier les gains : ressources statiques plus rapides, serveur d’origine moins sollicité
2. Bien définir la stratégie de mise à jour
   • CSS/JS : utiliser de préférence le numéro de version/le changement de nom de fichier
   • Images : évitez autant que possible les remplacements prolongés sous le même nom ; privilégiez plutôt un nouveau nom de fichier ou un changement de chemin, surtout pour les bannières de la page d’accueil et les visuels de campagne
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 requêtes du serveur d’origine sont-elles plus stables ? (liste de vérification ci-dessous)

5. Feuille de route de mise en ligne : progression en 3 phases (du stable au solide)

La raison pour laquelle le CDN est le plus facile à “ mettre en désordre ” dès sa mise en service, c’est qu’on veut activer toutes les capacités au maximum dès le départ.

Étape 1 : ne traiter que les ressources statiques CDN (fortement recommandé de commencer par cela)

les objectifsImages/CSS/JS/polices d’abord via CDN ; HTML non mis en cache dans CDN (ou inchangé pour l’instant)

Pourquoi commencer par cela est le plus sûr

• Risque minimal : la mise en cache des ressources statiques est erronée, jusqu'à “style/image non mis à jour”, contrôlable.
• Ne modifie pas l’état de connexion, le parcours d’achat ni l’exactitude des informations du compte
• Vous verrez clairement les bénéfices : les ressources statiques se téléchargent plus vite, et le serveur d’origine reste plus stable

Questions fréquentes à cette étape

• Contenu mixte (la page charge HTTP ressources)
• La mise à jour des ressources statiques ne s’applique pas (URL inchangée)

---

Étape 2 : stratégie d’actualisation (priorité au numéro de version, purge/invalidation en secours)

C’est le point de bascule entre “ CDN, c’est pro ou pas ”.

Une règle absolue :

Pour les mises à jour pouvant être résolues en modifiant le numéro de version ou le nom du fichier, ne dépendez pas de la purge.

Pourquoi l’allongement de la chaîne de cache rend-il les choses si imprévisibles :

• Cache du navigateur : votre appareil a peut-être conservé un ancien CSS/JS
• Cache CDN : il se peut que le nœud de périphérie ait mis en cache une ancienne ressource
• Cache du site source : le plugin de cache / le cache serveur diffuse peut-être encore l’ancien contenu

Si vous n’avez pas de stratégie de versioning, la publication finira par devenir :
“Modification effectuée → actualiser → ne marche pas → vider à nouveau le cache → toujours pas → vider l’autre couche de cache”
C'est le principal problème que rencontrent de nombreuses personnes avec le CDN.

---

Phase 3 (avancé) : faut-il mettre en cache le HTML (gain élevé, mais risque maximal)

Le cache HTML (cache global/cache en périphérie) peut réduire nettement le TTFB, mais dans les environnements WordPress, c’est aussi une source fréquente d’incidents.

En cas de doute, ne mettez pas le HTML en cache. Commencez par du statique CDN + une extension de cache côté serveur d’origine.

Si vous souhaitez mettre en cache du HTML, deux principes :

1. Commencer uniquement depuis le mode visiteur: Mettre en cache uniquement les pages des visiteurs non connectés
2. Rédiger d’abord la liste d’exclusion: la priorité à la justesse, ensuite au taux de réussite

6. Liste des règles par scénario : que faire selon les différents types de site pour éviter tout incident

6.1 Site de contenu / blog (principalement des articles, beaucoup de visiteurs)

Recommandé

• Ressources statiques : cache complet
• HTML : il est possible d’envisager la mise en cache de la “ page visiteur non connecté ”

Généralement à contourner

• Back-office et connexion/wp-admin/*、/wp-login.php
• Aperçu/Brouillon
• Page des résultats de recherche (les paramètres varient beaucoup, mieux vaut ne pas mettre en cache pour l’instant)
• Requête POST de soumission de formulaire/commentaire

La clé de cache doit au moins distinguer

• Connecté ou non (dimension cookie)
• Langue du site multilingue

---

6.2 Site d’entreprise / page d’atterrissage marketing (formulaires, nombreuses campagnes)

Recommandé

• Ressources statiques : cache complet
• HTML : les pages publiques peuvent être mises en cache (visiteurs non connectés), mais il faut traiter avec prudence les pages de résultats de formulaire

Le piège le plus courant : les paramètres de suivi fragmentent le cache
Questions fréquentes de la page de destination utm_* Paramètres :

• Toutes les parties dans la clé de cache → cache fragmenté, faible taux de succès
• Tout ignorer → Certaines pages dont le rendu dépend de paramètres peuvent ne pas s’afficher comme prévu

---

6.3 Site membres / Site de cours / Communauté (forte part d’utilisateurs connectés)

ConclusionSoyez très prudent avec la mise en cache du HTML.
La méthode la plus sûre est généralement : CDN statique + cache du site source/cache d’objets ; le HTML n’est mis en cache que pour les visiteurs.

Doit contourner

• Connexion/Inscription/Mot de passe oublié
• Centre de compte, commandes/abonnements, profil
• Toute page et interface étroitement liées à l’espace utilisateur

---

6.4 Site e-commerce (WooCommerce)

Liste des contournements les plus importants

• Panier, paiement, compte
• Pages liées à la confirmation de commande et au retour de paiement
• Connexion/Inscription, coupons/points et autres accès liés au compte utilisateur

Pourquoi l’e-commerce est plus susceptible d’avoir des incidents

• Dès qu’un utilisateur a un panier, une session ou est connecté, la page devient fortement personnalisée
• Si le cache HTML n’est ni contourné ni différencié selon l’état, les conséquences les plus typiques sont : panier erroné, confusion de comptes, affichage des prix anormal
  Privilégiez l’exactitude, ne la sacrifiez pas au taux de réussite.

---

6,5 Site multilingue / multidevise

Recommandé

• Ressources statiques : cache complet
• HTML : l’état visiteur peut être mis en cache, mais la clé de cache doit clairement distinguer les variantes de langue et de devise

La clé de cache doit être prise en compte

• Langue (chemin) /en/ /zh/ ou sous-domaine en.）
• Connecté ou non (cookie)
• Devise/Taux de TVA (si affiché)

---

7. Avertissement sur les risques

Risque 1 : contenu mis en cache incorrect (le plus grave)

• Erreur de cache des ressources statiques : souvent styles/images anciens
• Erreur de cache HTML : mélange possible de contenu, de panier et de compte — il s’agit d’un incident grave

Risque 2 : la mise à jour ne prend pas effet（le plus courant）

Après l’allongement de la chaîne de cache, “ modifié mais pas pris en compte ” deviendra plus fréquent :

• Priorité aux modifications du numéro de version/nom de fichier
• Purge/Secours en cas d’échec
• Le processus de publication doit être reproductible (savoir quelles URL ont été modifiées à chaque publication)

Risque 3 : limites des engagements des versions gratuite et d’entrée de gamme

• Caractéristiques courantes des offres gratuites : quota limité, certaines fonctionnalités non incluses, SLA/support différents de l’usage commercial officiel

Risque 4 : les capacités liées à la Chine continentale sont facilement sujettes à malentendu

• ESA : si vous souhaitez emprunter une ligne en Chine continentale, vous devez effectuer l’enregistrement ICP chinois
• EdgeOne : si vous souhaitez utiliser les lignes de la Chine continentale, vous devez effectuer l’enregistrement ICP chinois

8 Liste de vérification : comment confirmer après la mise en ligne que cela a vraiment pris effet“

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 charge du site d’origine a-t-elle diminué ?

• La bande passante du site source est-elle plus stable
• Le nombre de requêtes/connexions au serveur d’origine a-t-il diminué (surtout pour les requêtes de ressources dupliquées)

La mise à jour est-elle contrôlable ?

• Modifier le CSS/JS ou remplacer une image une fois
• La nouvelle version peut-elle être appliquée rapidement via un changement de numéro de version ou de nom de fichier
• Si la mise à jour ne peut se faire qu’en passant par Purge, c’est que la stratégie de versionnement n’est pas encore au point (corrigez d’abord la stratégie, ne faites pas de Purge une routine).

8.4 La page clé dynamique est-elle correcte ?

(Indispensable pour les sites e-commerce/membres)

• Le contenu de la page après la connexion/la déconnexion est-il correct ?
• Les pages panier/paiement/compte sont-elles toujours correctes
• Une anomalie où différents utilisateurs voient le même contenu côté utilisateur est-elle apparue (critique)

8,5 Le taux d’erreur est-il en hausse ?

• Délai d’attente à l’origine, 5xx, indisponibilité intermittente
• Il s'agit généralement d'un support insuffisant à la source, de règles incorrectes, de déclencheurs de limite de vitesse ou de problèmes au niveau du lien vers la source.

9. Arbre de diagnostic des mises à jour non appliquées (transformer le “ miracle ” en étapes)

Commencez par déterminer à quel type de problème vous êtes confronté :

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

Cas A : vous seul voyez l’ancienne version, en navigation privée ou sur un autre appareil c’est la nouvelle
Priorité au cache du navigateur

• Solution : publier de nouvelles ressources si le numéro de version ou le nom de fichier change

Cas B : tout le monde voit l’ancienne version (même en navigation privée ou sur un autre appareil)
À soupçonner en priorité : CDN utilise encore l’ancien cache

• 99% Cause : l’URL de la ressource n’a pas changé
• Solution prioritaire : stratégie de version
• Solution de secours : Purge (mesure temporaire)

Cas C : après avoir remplacé une image par une autre du même nom, l’ancienne image s’affiche toujours
Problème classique de superposition du cache du navigateur et du cache CDN

• Conseil pratique : évitez autant que possible les remplacements prolongés sous le même nom ; utilisez un nouveau nom de fichier/chemin ou un numéro de version

---

9.2 HTML non mis à jour (le contenu/la section de la page est encore ancien)

Cas A : nouveau dans le back-office/après connexion, ancien pour les visiteurs
À soupçonner en priorité : le HTML en mode visiteur est resté en cache

• Confirmez d’abord : ce type de page doit-il mettre en cache le HTML ?
• S’il faut mettre en cache : une stratégie d’actualisation contrôlable est nécessaire, sinon la publication devient incontrôlable

Cas B : seuls certains pays/réseaux affichent encore l’ancien contenu
À suspecter en priorité : état du cache différent selon les nœuds en périphérie

• 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.

Cas C : anomalie utilisateur connecté/panier
Signal critique : il se peut que le mauvais contenu ait été mis en cache

• Vérifier immédiatement si des pages côté utilisateur sont mises en cache (panier/paiement/compte, etc.)
• Vérifier si la clé de cache ignore des variantes clés comme “ utilisateur cookie / langue / devise ”

10. recommandations

Cloudflare

• Proxy inverse intégré
• Adapté à : démarrage de l'épargne
• Point clé : la stratégie de version résout les mises à jour ; le cache HTML se fait à partir de l’état visiteur
• Risque : les pages dynamiques doivent être contournées

Tencent Cloud International EdgeOne

• Proxy inverse intégré
• Adapté à : prise en compte des capacités des nœuds de Chine continentale et intégration unifiée
• Gratuit : plan/version gratuit disponible, mais vérifiez bien les limites de quota et d’engagement
• Risque : planifier les quotas des règles/journaux/sous-domaines ; prudence avec le cache HTML

Aliyun International ESA

• Proxy inverse intégré
• Gratuit : disponible pour les comptes du site international, accès gratuit à Entrance
• Risque : les limites libres (SLA/support/limite de vitesse) et les zones/conditions de dépôt doivent être confirmées à l'avance.
• Convient pour : évaluation/tests et intégration légère ; ou mise à niveau ultérieure du forfait, ou prise en compte des capacités des nœuds en Chine continentale et de l’intégration unifiée

bunny.net

• Pull statique CDN
• Convient pour : commencer par une accélération statique à faible risque
• Point essentiel : priorité au numéro de version, Purge comme solution de secours ; éviter l’écrasement des éléments portant le même nom
• Risque : si la stratégie de mise à jour n’est pas bien définie, vous rencontrerez fréquemment d“” anciennes ressources »

11. Recommandations d’action

1. Choisissez d’abord le type : proxy inverse intégré (Cloudflare/EdgeOne/ESA) ou Pull statique CDN (bunny)
2. Déploiement par phase :D’abord statique → puis stratégie de version → enfin envisager le cache HTML
3. Après mise en ligne, vérifier selon la checklist : hit/origine/mise à jour/contournement dynamique/taux d’erreur
4. Besoin de plus de rapidité : retournez dans “ extension de cache ” et “ optimisation des images ”, puis recompressez encore une fois la couche du site d’origine et la couche des ressources

FAQ WordPress CDN

1) Pourquoi le système est-il toujours lent après l'utilisation de CDN ?

La cause la plus fréquente n’est pas que CDN soit inutile, mais que le goulot d’étranglement ne se situe pas au niveau de la “ couche de livraison ”.

Vous pouvez juger dans cet ordre :

• TTFB reste élevéLe site source génère le HTML lentement (base de données/plugin/configuration du cache/performances de l’hébergement) → revenir au site source pour l’optimiser
• La grande image d’accueil 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)
• Scripts tiers lentsCourant pour les scripts pub/statistiques/service client → CDN n’aide généralement pas, il faut réduire ou retarder le chargement
• Seulement certaines régions sont lentes: Il peut s’agir d’une couverture des nœuds, de lignes de retour à l’origine, ou d’un cache non atteint (faible taux de hit) → vérifier le taux de hit et la situation de retour à l’origine

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

---

2. Pourquoi les utilisateurs voient-ils encore l’ancienne version après la mise à jour du CSS/JS/des images ?

Il s'agit du problème le plus courant dans les scénarios CDN et la raison principale en est généralement la suivante :L’URL de la ressource n’a pas changé, le système de cache continuera à utiliser raisonnablement l’ancien cache.

Le principe du traitement le plus stable :

• Priorité au numéro de version: modifier l’URL de la ressource (par exemple style.css?ver=xxxx ou nom de fichier hash)
• Purge par défaut: N’effacez le cache comme solution temporaire que si vous n’avez pas encore défini de stratégie de versioning.

Si vous remplacez souvent la bannière d’accueil ou les visuels de campagne, évitez d’écraser un fichier du même nom et privilégiez un nouveau nom de fichier ou un nouveau chemin plus maîtrisable.

---

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.

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

• Ressources statiques (images/CSS/JS/polices) plus rapides
• Réduction de la charge de l’origine et amélioration de la stabilité

HTML en cache Les gains peuvent certes être plus importants (TTFB plus faible), mais le risque est aussi le plus élevé : e-commerce, espace membre, contenu personnalisé, multilingue/multidevise, tout cela peut facilement être mal mis en cache.

Itinéraire sûr

1. Première statique CDN (faible risque, forte récompense)
2. Finaliser la stratégie de version et la checklist de validation
3. Réévaluer si le HTML doit être mis en cache (à partir du mode visiteur)

---

4. Un site e-commerce peut-il installer CDN ? Est-ce que ça risque de perturber le panier ?

C’est possible, et il faut le faire (au moins pour les ressources statiques), mais il faut éviter de mettre en cache les pages côté utilisateur.

• Les ressources statiques peuvent être mises en cache: Images, CSS, JS
• La page en mode utilisateur doit être contournéeNe mettez pas en cache le HTML des pages liées au panier, au paiement et au compte.
• Tant que vous ne mettez pas ces pages en cache HTML, le risque de mélange de panier ou de compte sera fortement réduit.

---

5. Comment créer un site multilingue/multidevise CDN sans mélange de langue ni de prix ?

L’essentiel est dans Clé de cache Est-ce correct ?

• Langue (chemin ou sous-domaine)
• Devise (si cela influence l’affichage du prix)
• Connecté ou non (cookie)
• Région/Taux de taxe (si la page change selon la région)

Si ces dimensions n’entrent pas dans la logique de mise en cache, on risque facilement de voir apparaître ceci : des utilisateurs en langue A voient du contenu en langue B, ou des prix incohérents.

---

6. Dois-je choisir le reverse proxy tout-en-un (Cloudflare/EdgeOne/ESA) ou le Pull statique CDN (bunny) ?

Vous pouvez choisir selon l“” objectif “ et la ” tolérance au risque » :

• Tout régler d’un coup HTTPS + CDN + sécurité de base, avec extension possible des règles/WAF ensuiteProxy inverse intégré
• Vous voulez d’abord faire le premier pas le plus sûr possible (ressources statiques plus rapides), sans toucher au proxy de tout le site :Pull statique CDN(par exemple bunny)

Si vous hésitez, un conseil par défaut s'impose :Statique d’abord CDN Valider la stratégie de version et la checklist, puis décider d’activer ou non le cache proxy/HTML

---

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

Utilisable, mais il faut considérer “ gratuit ” comme un usage de démarrage/d’évaluation/léger, pas comme une offre officielle avec SLA commercial.

• Acceptez-vous la formule gratuiteLimite de quota, fonctionnalités manquantes, différences de support et éventuelle absence d’engagement SLA？
• Si ce n’est pas possible, considérez l’offre gratuite comme un essai, puis passez ensuite à une formule plus adaptée

---

8. Comment puis-je confirmer que CDN a réellement pris effet, et que ce n’est pas juste un effet placebo ?

Confirmez en trois étapes (sans aucun outil complexe) :

1. Vérifier si les ressources statiques sont renvoyées depuis CDNLa source des images/CSS/JS a-t-elle changé ?
2. Voir si le taux de réussite et le retour à l’origine s’améliorent(La hausse du taux de hit et la baisse du trafic retour origine sont les vrais gains)
3. Modifier une fois la stratégie de mise à jour de validation CSS/images(Le numéro de version prend effet, indiquant que le flux est maîtrisé)

Si vous n’arrivez pas à respecter le point 3, plus vous optimiserez ensuite, plus vous risquez d’être confronté au problème des “ mises à jour qui ne prennent pas effet ”. Il est recommandé de compléter en priorité votre stratégie de versionnement.

---

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 la sélection de la zone et les conditions de classement。

• Si vous souhaitez choisir une zone d’accélération incluant la Chine continentale, il faut généralement d’abord terminer Enregistrement ICPLes sans-papiers ne peuvent sélectionner que des régions n'incluant pas la Chine continentale.

---

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

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

1. Couche d’origine : stabiliser d’abord l’extension de cache / l’hébergement de base (baisse du TTFB, baisse de la charge du back-office)
2. Couche de ressources : optimisation de l'image pour en réduire la taille
3. Couche de livraison : CDN Fournir des ressources plus rapidement et de manière plus cohérente

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