Plugins de cache WordPress : ce qu’ils font vraiment, et ça dépend de votre serveur

Installé et activé sans toucher un réglage, un seul des six plugins testés met votre site en cache quel que soit le serveur : Cache Enabler. Un deuxième, LiteSpeed Cache, ne le fait que sur OpenLiteSpeed. Les quatre autres écrivent des fichiers dans votre installation et ne servent rien tant qu’on ne coche pas leur interrupteur.

Ce qu’on a mesuré, et comment

Un plugin de cache ne fait pas la même chose selon le serveur web placé devant lui. Apache lit le fichier .htaccess. nginx l’ignore. OpenLiteSpeed le lit et possède son propre cache, intégré au serveur. Or plusieurs extensions jouent leur mode rapide dans .htaccess, et LiteSpeed Cache repose entièrement sur le cache d’un serveur LiteSpeed. Comparer six plugins sur un seul serveur, c’est les comparer dans les conditions d’un seul hébergeur.

Trois piles, en conteneurs, sur la même machine : Apache 2.4 et mod_php 8.3, .htaccess lu, la pile du mutualisé classique ; nginx et PHP-FPM 8.3, .htaccess ignoré, la pile de l’infogéré ; OpenLiteSpeed et lsphp 8.4, .htaccess lu et cache serveur intégré, la pile des hébergeurs sous LiteSpeed.

Même cœur WordPress, même contenu (80 articles, 200 commentaires, permaliens jolis), mêmes six extensions dans les mêmes versions : Cache Enabler 1.8.16, WP Fastest Cache 1.5.1, WP Super Cache 3.1.1, WP-Optimize 4.6.1, LiteSpeed Cache 7.9, W3 Total Cache 2.10.5. Chaque extension est activée seule, mesurée, puis supprimée par le bouton « Supprimer », et l’arborescence est restaurée depuis une photo prise avant toute mesure.

Deux configurations. Par défaut : activée, rien d’autre ; c’est ce que fait quelqu’un qui installe un plugin de cache parce qu’on le lui a conseillé. Cache activé : le banc coche l’interrupteur du cache de page, et seulement lui.

Trois questions, dans cet ordre.

Est-ce que ça cache vraiment ? Le temps ne sert jamais de preuve : une deuxième requête plus rapide, c’est aussi l’OPcache de PHP qui chauffe. Une ligne n’est comptée « cache actif » que si l’extension signe un en-tête HTTP, ou si une page complète a été écrite dans son dossier de cache. Sans preuve, la ligne dit non, et ses millisecondes ne comptent pas.

Est-ce que ça va vite ? Temps jusqu’au premier octet de l’accueil : la première requête après activation (à froid), puis la médiane de dix requêtes (à chaud). Les mesures sont prises sur la machine des conteneurs, sans réseau : ce sont des écarts entre extensions, pas ce que verra un visiteur.

Qu’est-ce que ça casse, ou qu’est-ce que ça laisse ? On publie un article par XML-RPC, comme un éditeur depuis l’administration, et on relève au bout de combien de secondes l’accueil le montre. On se connecte par wp-login.php et on vérifie que la session ne reçoit pas la page publique. On interroge robots.txt et wp-login.php. On relève tout fichier apparu hors du dossier de l’extension et toute modification de .htaccess. Après suppression, on vérifie que le site répond encore.

Une première série, fin août, a été jetée en entier pour des artefacts de protocole : une sonde qui perdait une course dans un tube shell, un en-tête Accept que Cache Enabler refuse, une photo de référence contaminée. Les défauts ont été prouvés, corrigés, et tout a été remesuré le 10 septembre 2026.

Par défaut : un seul plugin cache, sur les trois serveurs

Temps à chaud, en millisecondes, extension activée sans aucun réglage. « non » signifie qu’aucune preuve de cache n’a été trouvée.

Entre 64 et 84 ms, c’est l’accueil reconstruit par WordPress à chaque visite. Les écarts dans cette plage sont du bruit.

Cache Enabler n’a pas d’interrupteur. Il cache dès l’activation, signe chaque page d’un en-tête X-Cache-Handler: cache-enabler-engine, et l’accueil montre un article publié une seconde plus tard. Il est le seul à le faire sur les trois serveurs.

LiteSpeed Cache a son option de cache sur « activé » dès l’installation. Sur OpenLiteSpeed : 1 ms et un en-tête x-litespeed-cache: hit. Sur Apache et nginx : 76 et 72 ms, et rien d’autre. L’extension demande au serveur de cacher, et le serveur n’est pas un LiteSpeed.

Les quatre autres ont un interrupteur, sur « arrêt ». WP Super Cache et W3 Total Cache préparent pourtant le terrain sans rien servir : WP_CACHE dans wp-config.php, un advanced-cache.php, un dossier de configuration. WP-Optimize et WP Fastest Cache n’écrivent rien tant qu’on ne coche rien.

Cache activé : cinq plugins sous 10 ms, et deux façons de purger

Temps à chaud après que le banc a coché l’interrupteur de cache de page, et rien d’autre. La dernière colonne est le délai au bout duquel l’accueil montre un article qui vient d’être publié.

WP Super Cache, WP-Optimize et W3 Total Cache donnent le même résultat sur les trois serveurs. Elles servent leur page depuis PHP, par advanced-cache.php, avant que WordPress ne se charge ; le serveur web n’a pas voix au chapitre.

WP Fastest Cache est différente. Sur Apache, elle ajoute des règles à .htaccess et la page tombe à 1 ms : tout indique que le serveur sert le fichier lui-même, sans PHP. Sur nginx, elle n’écrit pas ces règles et sert par PHP, à 6 ms. Sur OpenLiteSpeed, elle écrit les règles, et la page reste à 7 ms. Le banc constate cet écart sans l’expliquer. Dans les trois cas, le gain est d’un facteur dix.

Puis vient la purge. Quatre extensions montrent l’article publié au bout d’une seconde. W3 Total Cache le montre au bout de 30 secondes, sur les trois serveurs et sur deux séries de mesures : c’est son délai, pas un accident. WP Fastest Cache ne le montre toujours pas au bout de 60 secondes.

Ce dernier résultat demande une précision. WP Fastest Cache n’a pas de défaut de purge. Dans sa page de réglages, « Enable » est une case, et « New Post » (vider le cache à la publication) en est une autre. Le banc n’a coché que la première, par construction. Le résultat dit donc : si vous activez ce plugin en ne cochant que le cache, votre accueil ignore vos nouveaux articles jusqu’à expiration ou vidage manuel. La deuxième case n’est pas optionnelle.

Sur un point, les six se valent : connecté par wp-login.php avec un vrai compte, aucun des dix-sept caches actifs du banc n’a servi la page publique à la session.

Ce que les extensions écrivent chez vous

C’est la partie qu’aucun test de vitesse ne mesure, et celle qui transforme un essai en panne. Un plugin de cache ne vit pas dans son dossier : il écrit dans wp-config.php, dépose un advanced-cache.php dans wp-content, et parfois réécrit .htaccess. Relevé par comparaison de l’arborescence avant et après activation, en configuration par défaut :

Une fois le cache activé, WP-Optimize rejoint les autres (WP_CACHE, advanced-cache.php, cache/, wpo-cache/), et WP Fastest Cache écrit cache/ plus des règles dans .htaccess sur Apache et OpenLiteSpeed, mais pas sur nginx.

Deux lignes méritent qu’on s’y arrête. W3 Total Cache et LiteSpeed Cache modifient .htaccess dès l’activation, avant de servir la moindre page. Sur nginx, où il n’existait pas, elles le créent à la racine du site. Le serveur ne le lira jamais. Le fichier est inoffensif là où il est, jusqu’au jour où le site migre vers un hébergeur Apache, qui appliquera des règles écrites pour un cache qui n’a peut-être plus lieu d’être.

Après désactivation puis suppression, les six extensions laissent un site qui répond 200, sur les trois serveurs. Cela n’allait pas de soi : un advanced-cache.php orphelin suffit à casser un site. Le banc ne vérifie pas que WP_CACHE et advanced-cache.php ont été retirés ; il vérifie que le site tient.

Le serveur compte

LiteSpeed Cache compte sept millions d’installations actives. Son cache de page n’est pas fait par l’extension mais par le serveur LiteSpeed, à qui elle envoie des instructions par en-têtes. Sur Apache ou nginx, personne ne les lit.

Le banc le montre : 1 ms sur OpenLiteSpeed avec x-litespeed-cache: hit, purge en 1 s, rien servi au connecté ; 76 et 72 ms sur Apache et nginx par défaut, 75 et 84 ms une fois l’option reposée, aucun en-tête, aucune page sur le disque. Sur ces deux serveurs, l’extension écrit quand même WP_CACHE, son dossier litespeed/ et ses règles .htaccess. Rien dans l’extension ne dit à l’utilisateur que le cache ne s’applique pas chez lui.

Une limite connue vaut une phrase, parce qu’elle a piégé notre propre banc : si vous publiez par WP-CLI ou par un script qui ne passe pas par le serveur web, LiteSpeed Cache met la purge en file et la déclenche par un appel HTTP à votre site. Si cet appel est bloqué, la page reste servie jusqu’à l’expiration, sept jours par défaut. Depuis l’éditeur de WordPress, la purge part avec la réponse.

WP Fastest Cache est l’autre extension dont le résultat dépend du serveur : 1 ms là où Apache lit ses règles, 6 et 7 ms ailleurs. Les trois autres extensions à fichiers ne dépendent de rien.

Comment choisir selon votre serveur

Ce tableau ne classe pas les hébergeurs. Il dit ce que le banc a mesuré sur chaque pile. Pour savoir laquelle est la vôtre, l’en-tête Server: de votre site répond en général (Apache, nginx, LiteSpeed), et votre hébergeur le sait toujours.

Repères pour le parc français : le mutualisé historique, OVH en tête, est sous Apache ; les offres infogérées tournent souvent sous nginx ; o2switch et Hostinger sont sous LiteSpeed. Ce sont des repères, pas des recommandations : nous n’avons aucun lien d’affiliation avec ces hébergeurs à la date de publication, et si cela change, ce sera écrit ici. Aucun lien affilié dans cette page ; notre règle est sur la page Transparence. La pile de quinze hébergeurs, avec une source datée par cellule, est relevée dans Quelle pile serveur chez chaque hébergeur WordPress ?

Deux règles sortent du banc, quelle que soit la pile. Un plugin de cache activé n’est pas un cache actif : vérifiez. Et l’interrupteur n’est pas le seul réglage qui compte : la purge à la publication en est un autre.

Les limites du banc

• Un seul site, léger. 80 articles, thème par défaut, ni constructeur de pages ni boutique. Les 64 à 84 ms sans cache seraient bien plus hauts sur un site chargé.
• Des millisecondes locales. Les requêtes partent de la machine des conteneurs. Réseau, TLS et CDN s’ajoutent par-dessus. Lisez les écarts, pas les valeurs.
• Une version par extension, mesurée le 10 septembre 2026. Un correctif peut sortir demain.
• Une seule case cochée pour la variante. Aucun préréglage, aucune optimisation d’images, de scripts ou d’objets. W3 Total Cache et LiteSpeed Cache font bien d’autres choses que le cache de page ; elles n’ont pas été mesurées.
• Cache Enabler n’a pas de ligne « cache activé » : il n’a pas d’interrupteur, sa ligne par défaut vaut pour les deux configurations. Une ligne portant cette étiquette existe dans le fichier OpenLiteSpeed ; elle vient d’une passe antérieure à la correction de l’en-tête Accept et n’est pas retenue.
• Le témoin bouge. La page sans extension varie de 64 à 84 ms d’une passe à l’autre. À froid, la première requête d’une extension qui ne cache pas monte jusqu’à 159 ms : c’est la compilation de son code, pas un cache. Aucune conclusion n’est tirée d’un écart inférieur à 20 ms entre deux lignes sans cache.
• OpenLiteSpeed tourne en lsphp 8.4, les deux autres piles en PHP 8.3.
• Le cache d’objets est hors sujet. Redis Object Cache et ses semblables répondent à une autre question.
• Nous n’éditons aucun des plugins mesurés, et aucun hébergeur cité ne nous rémunère.

Refaire la mesure

Tout tient dans un dossier : un docker-compose.yml qui monte les trois piles sur des ports locaux, un installer.sh qui installe le même WordPress, le même contenu et les mêmes extensions partout, et un mesure.sh qui déroule le protocole et écrit une ligne par extension dans un CSV par pile. Rien n’est installé sur la machine hôte. Les trois CSV sont publiés avec les scripts, y compris les lignes de la première série jetée, marquées par leur date.

Dépôt : https://github.com/chirtesandrei/banc-cache-wordpress

Pour vérifier chez vous, sans rien installer, deux requêtes identiques suffisent. Envoyez l’en-tête Accept d’un navigateur, sinon certaines extensions ne serviront pas leur cache :

curl -sI -H 'Accept: text/html' https://votre-site.fr/ | grep -i -E 'x-cache|x-litespeed|x-wp-fastest'
curl -sI -H 'Accept: text/html' https://votre-site.fr/ | grep -i -E 'x-cache|x-litespeed|x-wp-fastest'

Un en-tête X-Cache-Handler ou x-litespeed-cache: hit à la deuxième requête dit qu’une copie est servie. Rien du tout ne prouve rien : WP Super Cache, WP-Optimize, W3 Total Cache et WP Fastest Cache ne signent pas leurs pages. Pour celles-là, regardez si des fichiers HTML apparaissent dans wp-content/cache/ après une visite anonyme. Puis publiez un brouillon et rechargez l’accueil dans une fenêtre privée.

Si vous trouvez un résultat différent des nôtres sur l’une de ces versions, dites-le nous. Une mesure qu’on ne peut pas contredire ne vaut pas grand-chose.

Ce que ça change pour vous

Un plugin de cache se choisit en général sur la réputation ou le nombre d’installations. Le banc dit autre chose. À réglage égal, quatre extensions font le même travail sur les trois serveurs, à 2 ou 3 ms, et la différence se joue sur ce qu’elles écrivent chez vous et sur la façon dont elles purgent. Une extension ne cache qu’à condition que votre hébergeur soit sous LiteSpeed, et ne vous le dit pas. Une seule cache sans qu’on lui demande.

Avant d’installer, sachez sur quel serveur vous êtes. Après avoir activé, vérifiez qu’une page est réellement servie depuis un cache. Puis publiez un article et regardez votre accueil. Trois minutes, et c’est la différence entre un cache et l’impression d’en avoir un.