3 min de lecture
Un CDN WordPress peut servir des images, styles et scripts depuis un réseau intermédiaire. Pour vérifier qu’il aide votre site, partez d’une ressource réelle et observez sa réponse plutôt que de vous fier au seul état du réglage.
Suivre une ressource
- URL du fichier
- Réponse et en-têtes
- Origine ou CDN
Qu’est-ce qu’un CDN pour WordPress ?
- Un CDN est un réseau qui distribue des ressources du site, comme les images et les feuilles de style, depuis des serveurs intermédiaires.
- Selon les règles du fournisseur, le CDN sert une copie en cache ou transmet la demande à l’hébergement d’origine.
- Le contrôle consiste à identifier quel fichier arrive réellement au navigateur et d’où il provient.
Ouvrez une page publique et repérez une image ou une feuille CSS dans l’onglet Réseau du navigateur. Relevez l’adresse, le code HTTP et les en-têtes. Selon le montage, l’adresse peut utiliser un domaine dédié ou rester sur le domaine du site derrière un proxy.
Les éléments à relever avant une purge
- L’adresse du fichier réellement demandé par la page.
- Son code HTTP et ses en-têtes de réponse.
- La version attendue du fichier, disponible sur l’hébergement ou dans le dernier déploiement.
Quand un CDN est-il utile pour un site WordPress ?
Si des visiteurs éloignés téléchargent les mêmes images ou fichiers CSS, un point de présence proche peut réduire la distance parcourue. Si le serveur d’origine met du temps à générer une page dynamique, mesurez cette réponse séparément avant d’attribuer la lenteur à la diffusion des fichiers.
Lire la réponse du CDN
Cherchez les en-têtes de cache propres à votre fournisseur. Comparez deux requêtes vers le même fichier depuis une session sans connexion et vérifiez qu’un cache navigateur ne masque pas la réponse réseau. Un premier accès peut être une absence en cache, puis la requête suivante peut être servie depuis le cache selon les règles actives.
Pour un fichier CSS ou JavaScript, relevez aussi son type de contenu et son adresse finale si la requête est redirigée. Un en-tête de compression, comme gzip, décrit l’encodage de la réponse. Pour vérifier la mise en cache, utilisez l’en-tête prévu par le CDN et confrontez-le à la règle appliquée à cette ressource.
Distinguer fichier périmé et erreur d’origine
Si le fichier est ancien, comparez son URL et sa version avec celles attendues, puis purgez la ressource concernée quand votre outil le permet. S’il répond en erreur, comparez l’état du fichier sur l’hébergement et les événements du fournisseur. Une erreur de connexion à l’origine ne se corrige pas forcément en vidant un cache.
Exemple de diagnostic
Si une feuille CSS répond en 200 mais semble ancienne, comparez l’URL exacte et les en-têtes de deux chargements. Si le navigateur sert une copie locale, rechargez avec le cache navigateur désactivé dans les outils de développement avant de conclure.
Vos images ou styles répondent mal derrière le CDN ?
Je peux examiner la diffusion des fichiers et identifier le réglage qui pose problème.
Vérifier les pages qui doivent rester dynamiques
Contrôlez une page publique, l’administration et un formulaire. Si votre configuration met aussi du HTML en cache, vérifiez ses exclusions et ce qui se passe après une publication. Documentez le fichier testé, les en-têtes obtenus et le réglage changé.
Si le navigateur bloque une ressource HTTP sur une page HTTPS, vérifiez aussi le contenu mixte. Contenu mixte WordPress : retrouver et corriger les ressources HTTP
Suivre une feuille de style qui reste ancienne après publication
Une nouvelle feuille de style est correcte sur l’hébergement, mais un navigateur sans connexion charge encore l’ancienne. Relevez l’adresse exacte du fichier et comparez les réponses avant de purger.
- Si la page appelle une ancienne adresse, examinez d’abord le HTML servi et les caches qui le conservent.
- Si l’adresse est correcte mais que le CDN sert un fichier ancien, utilisez une purge ciblée si disponible, puis refaites la même requête.
- Si l’origine renvoie déjà une erreur ou une ancienne version, corrigez la source avant de tester de nouveau le CDN.
Vérifier le résultat
| Symptôme observé | Premier contrôle |
|---|---|
| Fichier présent mais ancien | Version de l’URL et purge ciblée |
| Fichier introuvable | Existence et chemin sur l’origine |
| Réponse sans cache | En-têtes et règle appliquée à la ressource |
- Le fichier s’affiche et répond correctement.
- Les en-têtes observés concordent avec la règle de cache.
- L’administration et les formulaires fonctionnent après le changement.
Consulter la documentation de référence.
Questions fréquentes
Un cache MISS indique-t-il une panne ?
Non. Il peut s’agir du premier accès, d’une ressource exclue du cache ou d’une réponse arrivée à expiration. Vérifiez la règle et le code de réponse.
Un CDN peut-il mettre les pages HTML en cache ?
Cela dépend des règles activées. Vérifiez les exclusions des pages personnalisées et des sessions connectées avant d’étendre la mise en cache du HTML.
Pourquoi une purge ne change-t-elle rien ?
Le navigateur ou le HTML peut encore utiliser une ancienne ressource, ou l’hébergement peut servir le fichier périmé. Comparez l’URL et les réponses avant de purger à nouveau.
Quel cache purger après une modification WordPress ?
Vérifiez d’abord si la version actuelle arrive jusqu’au CDN. Si la réponse d’origine est ancienne, purgez le cache WordPress ou celui de l’hébergeur. Si seule la réponse du CDN est ancienne, purgez l’URL concernée sur le CDN.
Pourquoi des images ne chargent-elles plus après activation ?
Ouvrez l’URL d’une image concernée et relevez son statut et son protocole. Si la page HTTPS demande encore un fichier HTTP, consultez le guide du contenu mixte.
Faut-il mettre en cache les pages des utilisateurs connectés ?
Prévoyez une exclusion quand la page dépend de la session. Testez séparément deux sessions autorisées et une fenêtre privée pour vérifier que chacune reçoit le contenu attendu.
À retenir
Vérifiez une ressource publique et un parcours dynamique après avoir modifié votre CDN WordPress.
