CDN WordPress : ce qu’il accélère vraiment et comment bien le mettre en place
Un CDN WordPress accélère la livraison des fichiers statiques : images, CSS, JavaScript, polices. CDN signifie « Content Delivery Network », un réseau de serveurs répartis dans plusieurs pays. Ces serveurs servent une copie de vos fichiers depuis le point le plus proche du visiteur. Cela réduit la latence, c’est-à-dire le temps que met une donnée pour voyager entre le serveur et le navigateur.
Cependant, un CDN n’accélère pas tout. Il ne réduit pas le temps que WordPress met à générer une page dynamique. Il ne réduit pas non plus le temps de réponse de votre base de données. J’installe régulièrement des CDN sur des sites en production. Je constate souvent la même confusion : on l’installe en espérant régler un problème de lenteur qui vient en réalité du serveur ou du thème.
Dans ce guide, je détaille ce qu’un CDN accélère réellement. J’explique ensuite comment le mettre en place devant WordPress, avec les pièges classiques : cache de l’admin, API REST, et détection de l’IP réelle des visiteurs. Enfin, je propose une méthode simple pour mesurer le gain avant et après.
Ce qu’un CDN accélère vraiment
Les fichiers statiques : images, CSS, JS, polices
Le CDN excelle sur les fichiers qui ne changent pas souvent. Une image, une feuille de style ou un fichier de police peuvent être mis en cache pendant des jours, voire des mois. Le visiteur les récupère donc depuis un serveur proche de chez lui, plus rapidement.
Par exemple, un visiteur à Lyon qui charge une image hébergée à Paris passera par un point de présence CDN plus proche géographiquement, si le réseau en dispose un. En pratique, le gain dépend surtout de la distance et de la taille des fichiers.
La réduction de charge sur le serveur d’origine
Autre effet réel : moins de requêtes arrivent sur votre serveur d’hébergement. Le CDN les absorbe à sa place. Cela libère des ressources pour traiter les vraies pages dynamiques. Le temps de réponse peut donc s’améliorer indirectement aux heures de forte affluence.
C’est utile en cas de pic de trafic, par exemple après une campagne publicitaire ou une mention dans la presse.
Ce qu’un CDN n’accélère pas
Le temps de génération des pages PHP
WordPress génère chaque page en interrogeant sa base de données. Il exécute aussi du code PHP à chaque visite. Ce temps de calcul s’appelle le TTFB, pour time to first byte : le délai avant le premier octet reçu. Ce délai dépend de votre hébergement, de votre thème et de vos plugins, pas du CDN.
Si votre site est lent à générer ses pages, un CDN ne réglera pas ce problème de fond. Il faut alors travailler sur le cache de page côté serveur. Je détaille ce sujet dans mon guide sur les performances WordPress, cache, CDN et hébergement.
Les requêtes vers la base de données
Un formulaire de contact, une recherche interne, ou l’ajout d’un produit au panier déclenchent des requêtes en base de données. Le CDN ne touche pas à cette mécanique. Ces actions restent donc traitées par votre serveur d’origine.
Par ailleurs, un CDN ne remplace jamais un plugin de cache de page. Les deux fonctionnent en complément, pas en substitution.
Mettre en place un CDN devant WordPress
Choisir entre CDN généraliste et CDN proxy inversé
Deux approches existent. La première consiste à servir uniquement les fichiers statiques via un CDN classique, souvent branché sur une extension de cache. La seconde consiste à placer tout le trafic derrière un CDN qui agit comme proxy inversé. Un proxy inversé est un intermédiaire qui reçoit toutes les requêtes avant de les transmettre au serveur.
La seconde option demande plus de rigueur, car elle touche à l’admin et à l’API REST. J’y reviens plus loin.
Étapes de mise en place
- Sauvegardez votre site avant toute modification, base de données et fichiers compris.
- Créez un compte chez le fournisseur CDN choisi et ajoutez votre domaine.
- Configurez les enregistrements DNS pour pointer vers le CDN, selon les instructions du fournisseur.
- Activez la mise en cache pour les extensions de fichiers statiques (jpg, png, css, js, woff).
- Excluez explicitement les chemins d’administration et l’API REST du cache, voir section suivante.
- Testez le site en navigation privée, puis videz le cache du CDN si besoin.
- Vérifiez que le certificat HTTPS reste valide sur le domaine final.
Exemple de règle d’exclusion de cache
Voici un exemple de configuration pour exclure l’admin et l’API REST du cache. Adaptez-le selon votre fournisseur CDN :
Ne pas mettre en cache si l'URL contient :
/wp-admin/
/wp-login.php
/wp-json/
?preview=true
La plupart des interfaces CDN proposent un champ « exclusions » ou « bypass cache ». Il suffit d’y coller ces chemins.
Les pièges du cache CDN sur WordPress
Le cache de l’admin, source de bugs fréquents
Si le CDN met en cache les pages de /wp-admin/, l’éditeur peut afficher un contenu obsolète. Pire, un autre utilisateur peut voir une session qui n’est pas la sienne. J’ai vu ce cas sur des sites mal configurés, avec un CDN en mode proxy trop agressif.
La règle est simple : toute URL sous /wp-admin/ et /wp-login.php doit systématiquement passer en direct vers le serveur d’origine, sans cache.
L’API REST cassée par un cache trop large
WordPress utilise une API REST, une interface qui permet à l’éditeur Gutenberg d’échanger des données avec le site. Les applications mobiles et d’autres services l’utilisent aussi. Si le CDN met en cache les réponses de /wp-json/, l’éditeur peut afficher des erreurs de sauvegarde ou des données périmées.
Concrètement, exclure /wp-json/ du cache évite la majorité de ces soucis. Pour aller plus loin, je détaille ce point dans mon article sur le durcissement avancé de l’API REST WordPress. La documentation officielle de l’API REST est également consultable sur developer.wordpress.org.
La perte de l’IP réelle des visiteurs
Quand un CDN agit en proxy inversé, toutes les requêtes semblent provenir de ses propres serveurs. Sans configuration adaptée, WordPress voit alors l’IP du CDN au lieu de celle du visiteur. Cela fausse les statistiques, les blocages anti-spam et les règles de sécurité basées sur l’IP.
La solution consiste à activer la transmission de l’en-tête X-Forwarded-For côté CDN. Il faut ensuite configurer le serveur pour le lire correctement. Voici un exemple pour un fichier .htaccess sur Apache, à tester d’abord sur une copie du site :
<IfModule mod_remoteip.c>
RemoteIPHeader X-Forwarded-For
RemoteIPTrustedProxy 203.0.113.0/24
</IfModule>
L’adresse indiquée dans RemoteIPTrustedProxy doit correspondre aux plages IP réelles de votre fournisseur CDN. N’utilisez jamais une plage générique. Consultez leur documentation avant d’appliquer cette règle en production.
Mesurer le gain avant et après la mise en place
Les métriques à relever avant modification
Avant d’activer le CDN, notez plusieurs indicateurs de référence. Relevez le temps de chargement total, le TTFB, et le poids des ressources statiques. Des outils gratuits comme PageSpeed Insights permettent de récupérer ces données facilement.
Ces mesures rejoignent les Core Web Vitals, un ensemble de signaux qui évaluent la vitesse et la stabilité visuelle d’une page. Je les détaille dans mon guide sur les Core Web Vitals et l’indexation WordPress.
Comment comparer objectivement
Faites vos tests depuis un réseau différent de votre bureau habituel. Un VPN ou un outil en ligne qui simule plusieurs localisations convient bien. Répétez chaque test trois fois pour lisser les variations. Comparez ensuite la moyenne avant et après.
| Indicateur | Avant CDN | Après CDN (attendu) |
|---|---|---|
| Temps de chargement des images | Élevé, dépend de la distance au serveur | Réduit si le point de présence est proche |
| TTFB (génération de la page) | Inchangé par le CDN seul | Inchangé, sauf ajout d’un cache de page |
| Charge sur le serveur d’origine | Plus élevée | Réduite, fichiers statiques déchargés |
| Poids total transféré | Variable | Similaire, sauf compression additionnelle |
Ne pas confondre gain perçu et gain mesuré
Un site peut sembler plus rapide après l’ajout d’un CDN. C’est parfois simplement parce que le cache navigateur a été vidé pendant les tests. C’est pourquoi il faut toujours comparer des mesures faites dans des conditions identiques, avec le même outil des deux côtés.
Questions fréquentes
Un CDN WordPress remplace-t-il un plugin de cache ?
Non. Le CDN accélère la livraison des fichiers statiques, tandis qu’un plugin de cache accélère la génération des pages PHP. Les deux sont complémentaires, pas interchangeables, pour de bonnes performances globales.
Le CDN WordPress améliore-t-il le classement Google ?
Il peut améliorer les Core Web Vitals, un signal de classement léger. Cependant, Google n’utilise ni le taux de rebond ni le temps passé sur le site comme critère de classement direct.
Comment savoir si mon CDN casse l’API REST ?
Ouvrez l’éditeur Gutenberg et observez les erreurs de sauvegarde ou de chargement des blocs. Vérifiez aussi la console du navigateur pour des erreurs liées à /wp-json/, signe d’un cache trop agressif.
Faut-il un CDN pour un petit site WordPress vitrine ?
Pas toujours indispensable si le trafic est faible et le serveur proche des visiteurs. En revanche, un CDN devient utile dès que l’audience est internationale ou que le site contient beaucoup d’images.
Conclusion
Un CDN WordPress bien configuré accélère les fichiers statiques et soulage votre serveur. Il ne remplace cependant jamais un travail de fond sur le cache de page et l’hébergement. Les pièges classiques restent l’admin, l’API REST et la détection de l’IP réelle des visiteurs. Si vous préférez déléguer ce sujet technique, je m’en occupe dans le cadre de la maintenance WordPress.
