Un cache mal réglé ruine plus de sites que l'absence totale de cache. J'ai vu des sites servir aux visiteurs la version en cache de la page d'un autre client sur un hébergement mutualisé, ou un formulaire de contact qui n'envoyait plus rien parce que la page était figée depuis trois semaines. Optimiser le cache WordPress ne se résume donc pas à installer un plugin et cocher "activer" : ça demande de distinguer les couches (navigateur, serveur, objet, CDN) et de savoir laquelle configurer en premier. Avant de comparer les 4 plugins qui reviennent le plus souvent chez mes clients, un point s'impose sur ce que chaque couche fait réellement.
Le cache, au sens large, consiste à stocker une version déjà calculée d'une ressource pour éviter de la regénérer à chaque requête. Sur WordPress, une page classique déclenche des dizaines de requêtes SQL et l'exécution de PHP pour reconstruire le HTML à chaque visite. Le cache serveur court-circuite ce calcul en resservant une page HTML statique. Le cache navigateur, lui, dit au navigateur du visiteur de garder en local les fichiers CSS, JS et images pour ne plus les retélécharger d'une page à l'autre.
Cache serveur vs cache navigateur : la confusion qui fait perdre du temps
La plupart des tutoriels mélangent les deux couches et donnent l'impression qu'un seul réglage suffit. En réalité, le cache serveur (page caching) et le cache navigateur (browser caching) répondent à deux problèmes différents et se configurent séparément :
- Le cache serveur évite de recalculer le HTML à chaque visite : c'est lui qui fait chuter le TTFB (temps de réponse serveur), la métrique la plus corrélée au LCP sur WordPress
- Le cache navigateur évite de retélécharger les fichiers statiques (CSS, JS, images, polices) sur les pages suivantes d'un même visiteur, via l'en-tête HTTP
Cache-Control
Un site peut avoir un excellent cache navigateur et un TTFB catastrophique si le cache serveur n'est pas actif, ou l'inverse. Avant de choisir un plugin, je vérifie toujours lequel des deux pose problème avec un audit technique qui isole le temps de réponse serveur du temps de rendu navigateur, sinon on optimise la mauvaise couche.
Comparatif des 4 plugins de cache WordPress les plus fiables
Avant de creuser la configuration, autant choisir le bon outil : voici les 4 plugins que j'installe le plus selon le type d'hébergement, avec leurs vrais points forts et limites.
| Plugin | Prix | Cache objet (Redis) | Compatible mutualisé | Mon verdict |
|---|---|---|---|---|
| WP Rocket | À partir de 59$/an (1 site) | Oui, en un clic | Oui | Le plus simple à régler sans toucher au code, mon choix par défaut pour un client non technique |
| LiteSpeed Cache | Gratuit | Oui, natif serveur | Seulement sur serveur LiteSpeed | Imbattable en performance si l'hébergeur tourne sous LiteSpeed (o2switch, par exemple), inutile sinon |
| WP Super Cache | Gratuit | Non | Oui | Fiable et léger, mais reste basique face aux besoins d'un site à fort trafic |
| W3 Total Cache | Gratuit (version Pro payante) | Oui | Oui, avec prudence | Le plus complet sur le papier, mais son interface touffue génère souvent des conflits mal diagnostiqués |
Un point que peu d'articles précisent : sur un hébergement mutualisé, le cache objet (Redis ou Memcached) est rarement disponible côté serveur. Installer WP Rocket ou W3 Total Cache et activer leur option "cache objet" sans que Redis tourne réellement côté serveur ne fait rien, et peut même générer une erreur silencieuse. Je vérifie systématiquement dans l'espace hébergeur avant d'activer cette case.
Configurer le cache serveur sans casser le site
Une fois le plugin choisi, trois réglages font 80% du travail. D'abord, le cache de page lui-même : générer une version statique du HTML pour les visiteurs non connectés, jamais pour les administrateurs ni pour les pages avec formulaire ou panier actif. Ensuite, la purge automatique : le cache doit se vider seul quand un article est publié ou modifié, sinon les visiteurs voient une version obsolète pendant des heures. Enfin, l'exclusion des URL dynamiques : pages de paiement, compte utilisateur, ou tout endpoint avec un token dans l'URL.
L'erreur que je corrige le plus souvent : un cache activé globalement qui sert la même page à tous les visiteurs alors qu'elle contient un contenu personnalisé (panier WooCommerce, message "connecté en tant que"). Le symptôme classique, ce sont des tickets support "je vois le panier d'un autre client" qui remontent après une mise en cache trop large. La règle simple : si une page affiche une donnée propre au visiteur, elle sort du cache de page, point final.
Cache navigateur, CDN et purge : les erreurs qui coûtent du trafic
Le cache navigateur se règle via l'en-tête Cache-Control, que la plupart des plugins gèrent automatiquement pour le CSS, le JS et les images. Le piège classique : une durée de cache trop longue (un an) sur un fichier CSS qui change encore régulièrement, ce qui oblige à renommer le fichier à chaque mise à jour pour forcer le rafraîchissement (technique du "cache busting" avec un hash dans le nom de fichier, automatique sur la plupart des thèmes récents).
Côté CDN, la logique est la même à plus grande échelle : les fichiers statiques sont dupliqués sur des serveurs répartis géographiquement pour réduire la distance entre le visiteur et le fichier. Un CDN sans purge automatique après modification d'image ou de thème pose le même problème que le cache serveur mal purgé : le visiteur voit une version périmée. Je documente systématiquement ce point de contrôle dans ma checklist d'audit SEO, parce que c'est la cause la plus fréquente de "j'ai modifié le site mais rien ne change" que je reçois en support.
Dernier repère utile : après toute modification visible (thème, image, CSS), vide le cache dans cet ordre précis pour éviter les faux négatifs : plugin de cache d'abord, puis CDN, puis cache navigateur en local (Ctrl+F5). Beaucoup de "ça ne marche toujours pas" viennent d'un cache navigateur local qu'on a oublié de vider en testant depuis son propre poste.
