Mettre en cache WordPress pour accélérer son site

WordPress génère ses pages dynamiquement. À chaque visite, PHP s’exécute, WordPress charge son cœur, le thème, les extensions, puis interroge la base de données pour construire la page HTML finale.

Sur un petit site peu visité, cela passe souvent inaperçu. Cependant, dès que le trafic augmente, ce modèle peut devenir coûteux. Chaque page vue consomme du CPU, de la mémoire, des requêtes SQL et parfois des appels externes. Le cache permet d’éviter de refaire le même travail inutilement.

L’idée est simple : quand une page ou une donnée a déjà été générée, on la garde temporairement pour la servir plus vite lors des prochaines visites. C’est moins romantique qu’un thème premium avec des animations partout, mais c’est souvent beaucoup plus efficace.

Pourquoi WordPress a besoin d’un cache

Sans cache, WordPress reconstruit chaque page à la demande. Cela implique plusieurs couches :

• chargement de WordPress ;
• chargement du thème actif ;
• chargement des extensions ;
• exécution des hooks et filtres ;
• requêtes SQL vers MySQL ou MariaDB ;
• génération du HTML ;
• envoi des fichiers CSS, JavaScript, images et polices.

Le cache réduit ce travail. Dans le meilleur cas, le serveur renvoie une version HTML déjà prête, sans recalculer toute la page. Le visiteur reçoit la réponse plus vite, et le serveur encaisse mieux les pics de trafic.

C’est particulièrement utile pour les pages publiques qui changent peu : articles, pages, catégories, archives, guides, fiches documentaires et contenus evergreen.

Les principales couches de cache WordPress

Il ne faut pas parler du cache WordPress comme d’un seul bouton magique. En pratique, plusieurs caches peuvent travailler ensemble.

Le cache page

Le cache page stocke le HTML complet d’une page. C’est le gain le plus visible sur un site éditorial ou vitrine.

Au lieu de demander à WordPress de reconstruire l’article à chaque visite, le plugin ou le serveur renvoie une version déjà générée. Pour les visiteurs anonymes, c’est souvent la meilleure optimisation.

WP Super Cache, par exemple, génère des fichiers HTML statiques depuis un site WordPress dynamique. Ces fichiers peuvent ensuite être servis à la plupart des visiteurs non connectés, sans exécuter tout WordPress.

Le cache navigateur

Le cache navigateur concerne les fichiers statiques : images, CSS, JavaScript, polices, icônes et fichiers médias. Le serveur indique au navigateur combien de temps il peut conserver ces fichiers localement.

Résultat : lors de la visite suivante, le navigateur ne retélécharge pas tout. Il réutilise ce qu’il possède déjà, ou demande simplement au serveur si le fichier a changé.

C’est là que les en-têtes HTTP comme Cache-Control, ETag et Last-Modified deviennent utiles.

Le cache objet

Le cache objet stocke des données WordPress déjà récupérées ou calculées. Il évite de refaire certaines requêtes SQL pendant les prochaines requêtes.

Par défaut, WordPress possède un cache objet non persistant pendant l’exécution d’une requête. Pour le rendre persistant entre plusieurs requêtes, on utilise généralement Redis ou Memcached.

Ce cache devient très intéressant sur les sites dynamiques, les sites membres, les boutiques WooCommerce, les gros catalogues, les sites avec beaucoup de métadonnées ou les interfaces admin très sollicitées.

Le cache serveur

Le cache serveur fonctionne en amont de WordPress. Il peut passer par Nginx FastCGI cache, Varnish, LiteSpeed Cache, un cache intégré à l’hébergeur, ou une couche edge chez un fournisseur spécialisé.

Bien configuré, ce type de cache évite même de lancer PHP pour les pages publiques. C’est excellent pour les performances, mais il faut gérer proprement les exclusions et la purge.

OPcache côté PHP

OPcache ne met pas vos pages WordPress en cache. Il met en cache le code PHP compilé. Ainsi, PHP n’a pas besoin de relire et recompiler les mêmes fichiers à chaque requête.

Sur un serveur moderne, OPcache doit être activé. C’est une optimisation de base pour WordPress, WooCommerce et presque toutes les applications PHP sérieuses.

Quel plugin de cache WordPress choisir ?

Le bon choix dépend surtout de votre hébergement.

• Sur Apache classique, WP Super Cache reste une option simple et fiable.
• Sur LiteSpeed ou OpenLiteSpeed, LiteSpeed Cache est généralement le choix naturel.
• Sur un site premium sans cache serveur natif, WP Rocket peut simplifier la configuration.
• Sur un hébergement managé, utilisez d’abord le cache fourni par l’hébergeur.
• Sur un serveur dédié, Nginx FastCGI cache, Redis et OPcache peuvent donner d’excellents résultats.

Le piège classique consiste à empiler plusieurs plugins de cache. En général, un site n’a besoin que d’un seul système de cache page. Ajouter plusieurs couches mal coordonnées peut provoquer des pages périmées, des paniers WooCommerce incohérents, des purges incomplètes et des bugs pénibles à reproduire.

Le cache, c’est comme le piment : très bon quand on dose correctement, absurde quand on en met dans tout.

WP Super Cache : encore utile ?

Oui, WP Super Cache peut encore convenir à un blog ou un site relativement simple. Il crée des fichiers HTML statiques, puis les sert à la majorité des visiteurs anonymes.

Il propose plusieurs modes de fonctionnement :

• Expert : très rapide, car les fichiers statiques peuvent être servis via les règles serveur ;
• Simple : plus facile à configurer, car le cache passe par PHP ;
• WP-Cache : plus flexible pour certains visiteurs connus, paramètres d’URL ou contenus spécifiques.

Pour un site moderne, je commencerais par le mode simple si vous voulez éviter les erreurs .htaccess. Ensuite, vous pouvez passer à une configuration plus agressive si l’environnement serveur est bien maîtrisé.

Avant toute modification de règles Apache, sauvegardez le fichier .htaccess :

cp .htaccess .htaccess.before-cache-changeCode language: CSS (css)

Si vous travaillez sur Nginx, sauvegardez plutôt le vhost concerné :

cp /etc/nginx/sites-available/example.com /etc/nginx/sites-available/example.com.before-cache-change

Ne modifiez jamais les fichiers du core WordPress

Ne modifiez jamais les fichiers présents dans wp-admin ou wp-includes. Ils appartiennent au cœur de WordPress. Une mise à jour peut écraser vos changements, et une modification maladroite peut casser l’administration.

Aujourd’hui, la compression se gère au niveau serveur ou CDN, avec gzip ou Brotli. Les fichiers JavaScript et CSS peuvent aussi être minifiés, différés ou chargés conditionnellement, mais cela doit se faire via le thème, une extension, un mu-plugin, ou la configuration serveur. Pas au marteau dans le core.

Activer gzip ou Brotli côté serveur

La compression réduit le poids des réponses texte : HTML, CSS, JavaScript, SVG, JSON et XML. Les images modernes comme AVIF, WebP, JPEG ou PNG sont déjà compressées. Les recompresser avec gzip ne sert généralement à rien.

Sur Nginx, une base gzip raisonnable ressemble à ceci :

gzip on;
gzip_comp_level 5;
gzip_min_length 1024;
gzip_vary on;
gzip_types
    text/plain
    text/css
    text/xml
    application/json
    application/javascript
    application/xml
    application/rss+xml
    image/svg+xml;

Si votre serveur et votre distribution proposent Brotli, vous pouvez aussi l’activer. Brotli donne souvent de bons résultats sur les fichiers texte, surtout avec un CDN ou un serveur bien configuré.

Testez ensuite les en-têtes :

curl -I -H "Accept-Encoding: br,gzip" https://www.example.com/Code language: JavaScript (javascript)

Vous cherchez une réponse contenant par exemple :

content-encoding: brCode language: HTTP (http)

ou :

content-encoding: gzipCode language: HTTP (http)

Utiliser Cloudflare ou un CDN avec WordPress

Un CDN rapproche les fichiers du visiteur. Les images, CSS, JavaScript et parfois le HTML peuvent être servis depuis un réseau mondial plutôt que depuis votre serveur d’origine.

Cloudflare APO va plus loin qu’un CDN classique pour WordPress, car il peut mettre en cache le HTML dynamique à la périphérie du réseau Cloudflare. Cloudflare indique que cette approche permet de servir le site WordPress depuis son edge network et de stabiliser le TTFB.

Attention toutefois : Cloudflare recommande de désactiver temporairement les plugins comme WP Rocket, W3 Total Cache ou équivalents lors de la mise en place d’APO, puis de tester leur réactivation seulement après validation. Plusieurs systèmes de cache peuvent produire des résultats inattendus.

Avec Cloudflare, surveillez les en-têtes :

curl -I https://www.example.com/Code language: JavaScript (javascript)

Vous pouvez notamment regarder :

cf-cache-status
cf-apo-via
cache-control
age
vary

Sur un site WordPress classique, une page publique doit idéalement produire un cache hit après la première visite. Sur une page de compte, panier ou checkout, le cache doit rester désactivé.

Les pages à exclure du cache

Un cache agressif est excellent sur un article public. Il devient dangereux sur les pages personnalisées ou transactionnelles.

Excluez toujours du cache :

• l’administration WordPress ;
• les pages de connexion ;
• les aperçus d’articles ;
• les pages de compte utilisateur ;
• les paniers WooCommerce ;
• les pages de paiement ;
• les pages de confirmation de commande ;
• les URLs contenant des nonces ou paramètres sensibles ;
• les réponses REST ou AJAX qui dépendent de l’utilisateur connecté.

Pour WooCommerce, vérifiez au minimum ces chemins :

/cart/
/checkout/
/my-account/
/wc-api/
/?wc-ajax=Code language: JavaScript (javascript)

Selon votre site, les slugs peuvent être traduits :

/panier/
/commande/
/mon-compte/Code language: JavaScript (javascript)

Un bon cache WordPress ne consiste pas à tout cacher. Il consiste à cacher fortement ce qui est public, puis à exclure proprement ce qui dépend du visiteur.

Cache et utilisateurs connectés

Les utilisateurs connectés voient souvent des contenus personnalisés : barre d’administration, compte, commandes, espace membre, prix spécifiques, formulaires préremplis ou contenus privés.

Par défaut, il vaut mieux ne pas servir le cache page complet aux utilisateurs connectés. Certains systèmes avancés savent gérer des fragments dynamiques, mais ce n’est pas un réglage à activer au hasard.

Sur un site éditorial simple, le choix sûr est clair : cache page pour les visiteurs anonymes, pas de cache page complet pour les utilisateurs connectés.

Purger le cache sans tout casser

Un cache doit être purgé quand le contenu change. Sinon, les visiteurs peuvent voir une ancienne version de la page.

En général, le cache doit se vider lors de ces actions :

• publication d’un article ;
• mise à jour d’un article ;
• modification d’une page importante ;
• changement de menu ;
• modification de widgets ou blocs globaux ;
• mise à jour du thème ;
• mise à jour CSS ou JavaScript ;
• changement de réglage WooCommerce ;
• import massif de produits.

Évitez le réflexe “purge everything” toutes les cinq minutes. Cela vide tout le cache, surcharge l’origine, puis force le site à tout reconstruire. Sur un gros trafic, c’est l’équivalent technique d’ouvrir toutes les fenêtres en plein hiver pour vérifier que le chauffage marche.

Tester si le cache fonctionne vraiment

Ne vous fiez pas uniquement au score PageSpeed. Testez les en-têtes HTTP et le comportement réel.

Commencez par une page publique :

curl -I https://www.example.com/un-article/Code language: JavaScript (javascript)

Relancez la commande deux ou trois fois. Selon votre stack, vous cherchez des indices comme :

x-cache: HIT
cf-cache-status: HIT
age: 120
x-cacheable: YES
cache-control: public, max-age=600Code language: HTTP (http)

Ensuite, testez une page qui ne doit pas être cachée :

curl -I https://www.example.com/checkout/Code language: JavaScript (javascript)

Vous cherchez plutôt :

cache-control: no-store, no-cache, must-revalidate
cf-cache-status: BYPASSCode language: HTTP (http)

Enfin, testez en navigation réelle : visite anonyme, visite connectée, ajout au panier, paiement test, formulaire, recherche interne et espace compte.

Réglages recommandés pour un site WordPress classique

Pour un blog, un magazine ou un site vitrine, cette base fonctionne bien :

• cache page activé pour les visiteurs anonymes ;
• expiration raisonnable entre 10 minutes et plusieurs heures ;
• purge automatique lors des publications ;
• cache navigateur long pour les images, CSS, JS et polices ;
• gzip ou Brotli activé ;
• OPcache PHP activé ;
• CDN activé pour les fichiers statiques ;
• HTML mis en cache au CDN seulement si les exclusions sont propres ;
• aucun cache page pour les utilisateurs connectés, sauf cas maîtrisé.

Si votre thème ou vos extensions génèrent trop de requêtes SQL, le cache masquera le problème pour les visiteurs anonymes, mais il ne le corrigera pas vraiment. Dans ce cas, lisez aussi WordPress : réduire le nombre de requêtes SQL des thèmes.

Réglages recommandés pour WooCommerce

WooCommerce demande plus de finesse. Une boutique mélange pages publiques, sessions, panier, compte client, stock, prix, coupons, moyens de paiement et emails transactionnels.

Vous pouvez généralement mettre en cache :

• la page d’accueil ;
• les pages CMS ;
• les articles de blog ;
• les pages catégories produits pour visiteurs anonymes ;
• les fiches produits simples, si les prix ne varient pas par utilisateur ;
• les fichiers statiques.

Vous devez exclure :

• le panier ;
• le checkout ;
• le compte client ;
• les endpoints WooCommerce ;
• les fragments AJAX du panier ;
• les pages avec prix personnalisés par rôle ou client ;
• les pages avec stock très sensible si la purge n’est pas fiable.

Sur WooCommerce, je recommande de valider le cache avec un vrai scénario de commande test. Une page qui charge vite mais affiche le panier d’un autre client n’est pas une optimisation. C’est un ticket support avec des flammes autour.

Nettoyer la base de données complète le cache

Le cache réduit la charge des pages publiques, mais une base WordPress encombrée peut encore ralentir l’administration, les tâches cron, les recherches, les sauvegardes et certaines pages dynamiques.

Si votre base contient des milliers de révisions, transients expirés, métadonnées orphelines ou options autoloadées trop lourdes, traitez aussi ce sujet. J’ai détaillé la méthode dans WordPress : nettoyage de la base de données et dans WordPress : nettoyer les tables wp_options et wp_postmeta.

Checklist cache WordPress

• Activer un seul système principal de cache page.
• Vérifier que le cache fonctionne pour les visiteurs anonymes.
• Exclure les pages dynamiques et transactionnelles.
• Activer gzip ou Brotli côté serveur ou CDN.
• Activer OPcache PHP.
• Utiliser Redis ou Memcached si le site est dynamique.
• Configurer le cache navigateur pour les fichiers statiques.
• Tester les en-têtes avec curl -I.
• Tester le site connecté et déconnecté.
• Valider les parcours WooCommerce avant de déclarer victoire.
• Surveiller les erreurs 404, 500 et les logs PHP après modification.
• Purger le cache seulement quand c’est nécessaire.

FAQ : cache WordPress

Un plugin de cache suffit-il à accélérer WordPress ?

Il peut fortement aider, surtout sur les pages publiques. Cependant, il ne corrige pas un thème lourd, des requêtes SQL lentes, un mauvais hébergement ou des scripts tiers bloquants.

Faut-il utiliser plusieurs plugins de cache ?

Non, évitez d’empiler plusieurs plugins de cache page. Combinez plutôt des couches complémentaires : cache page, cache navigateur, OPcache, cache objet et CDN, avec des responsabilités claires.

WP Super Cache est-il encore recommandé ?

Oui, pour un site simple ou un blog. Pour un WooCommerce, un site membre, un site fortement dynamique ou un serveur dédié, une configuration plus adaptée peut être préférable.

Cloudflare remplace-t-il un plugin de cache WordPress ?

Pas toujours. Cloudflare accélère les fichiers statiques et peut aussi cacher le HTML avec APO. Cependant, le cache serveur, la purge WordPress et les exclusions dynamiques doivent rester cohérents.

Pourquoi mon site affiche encore une ancienne version après modification ?

Un cache n’a probablement pas été purgé : plugin, cache serveur, CDN, navigateur ou cache objet. Identifiez la couche concernée avant de tout vider au hasard.

Peut-on mettre WooCommerce en cache ?

Oui, mais pas entièrement. Les pages publiques peuvent souvent être cachées. Le panier, le checkout, le compte client, les sessions et les endpoints dynamiques doivent être exclus.

Comment vérifier si une page est servie depuis le cache ?

Utilisez curl -I et regardez les en-têtes HTTP : x-cache, cf-cache-status, age, cache-control ou les en-têtes propres à votre hébergeur.

Sources

• Documentation WordPress : Cache
• WP Super Cache sur WordPress.org
• Documentation Cloudflare : Automatic Platform Optimization
• Documentation Cloudflare : activer le plugin WordPress et APO
• SkyMinds : réduire le nombre de requêtes SQL des thèmes WordPress
• SkyMinds : nettoyage de la base de données WordPress
• SkyMinds : nettoyer les tables wp_options et wp_postmeta

Report a typo