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

Le résultat le plus utile concerne les réglages. Dans les configurations testées le 10 septembre 2026, Cache Enabler présente des indices de cache dès l’activation sur les trois serveurs. LiteSpeed Cache en présente aussi sur OpenLiteSpeed. Pour WP Fastest Cache, WP Super Cache, WP-Optimize et W3 Total Cache, le banc n’en relève qu’après activation explicite du cache de page.

Ces observations concernent un site de test et des versions précises. Elles aident à savoir quoi vérifier chez vous ; elles ne désignent pas un vainqueur pour tous les sites WordPress.

Ce que signifient les temps affichés

Un cache de page conserve une copie du HTML pour éviter de reconstruire toute la page à chaque demande. Nous avons mesuré le temps jusqu’au premier octet, autrement dit le délai avant que le serveur commence à répondre. Les tableaux donnent la médiane des dix requêtes suivant une première mesure.

Les requêtes partent de la machine qui héberge les conteneurs. Un résultat de 2 ms n’est donc pas une promesse de chargement en 2 ms pour vos visiteurs : leur connexion, les images, les scripts et le rendu dans le navigateur interviennent ensuite. À cette échelle, des valeurs arrondies à 1 et 2 ms ne permettent pas de départager sérieusement deux extensions.

Le banc relève aussi des en-têtes HTTP et des fichiers de cache. Ces indices complètent les temps : un fichier écrit ne prouve pas, à lui seul, qu’il a servi à répondre à chaque requête. L’annexe détaille ces contrôles.

Sans réglage : deux comportements se distinguent

Voici les médianes après activation de l’extension, sans activation supplémentaire du cache dans ses options.

E : en-tête X-Cache-Handler: cache-enabler-engine relevé. H : en-tête x-litespeed-cache: hit relevé. — : aucun indice retenu par le protocole. Les en-têtes sont relevés sur une requête distincte des requêtes chronométrées.

Cache Enabler associe des temps faibles à son en-tête sur les trois piles. LiteSpeed Cache présente un HIT sur OpenLiteSpeed, mais aucun indice de cache de page sur les deux autres piles du banc. Les quatre autres extensions ne présentent pas d’indice dans cette configuration initiale.

Le bouton « Activer » de WordPress et l’activation du cache dans les réglages sont donc deux choses à distinguer. La présence de l’extension dans votre liste de plugins ne dit pas, à elle seule, si vos pages sont mises en cache.

Après activation du cache : regarder aussi la mise à jour des pages

Dans cette variante, le script active le cache de page. Il ne cherche pas le meilleur préréglage et n’active pas toutes les options d’optimisation.

F : fichier de cache détecté. E, H et — gardent le sens du premier tableau. Les observations de publication valent sur les trois piles, sauf indication contraire. Cache Enabler reprend sa configuration par défaut : ce ne sont pas trois mesures supplémentaires.

WP Super Cache et WP-Optimize affichent 2 ms sur chaque pile ; W3 Total Cache affiche 2 à 3 ms. WP Fastest Cache présente un écart entre Apache et les deux autres serveurs. Ces temps décrivent la série conservée, sans démontrer la cause de chaque différence ni la performance sous charge.

La mise à jour après publication mérite autant d’attention que la vitesse. Pour WP Fastest Cache, le script active le cache mais laisse désactivée l’option de purge « New Post ». Le nouvel article n’est pas visible au dernier contrôle. C’est un résultat obtenu avec ce réglage, pas la preuve que l’extension ne sait pas vider son cache à la publication.

Pour W3 Total Cache, le premier contrôle positif intervient au palier 30 secondes, après un contrôle négatif au palier 10. Le banc ne mesure pas un délai exact de 30 secondes et ne permet pas d’en faire une caractéristique permanente de l’extension.

Le serveur compte, mais son nom ne suffit pas

Dans notre configuration OpenLiteSpeed, LiteSpeed Cache obtient un HIT et une médiane de 1 ms. Sur Apache et Nginx, le banc n’enregistre aucun indice de cache de page pour cette extension, y compris dans la variante où son option est activée.

Cela correspond à son architecture : le cache de page dépend d’un composant LSCache côté serveur. Les autres fonctions d’optimisation et l’utilisation de QUIC.cloud constituent des cas distincts, non mesurés ici. La documentation LiteSpeed précise ces prérequis.

Pour appliquer ces résultats à votre site, demandez à votre hébergeur quel cache est déjà en place et quelle intégration WordPress il prévoit. Le nom d’un hébergeur ou un en-tête Server ne décrit pas nécessairement toute la chaîne entre WordPress et le visiteur. Le banc ne compare aucune offre commerciale et ne teste ni cache FastCGI, ni Varnish, ni CDN.

Ce que les extensions modifient dans WordPress

Le cache peut écrire hors du dossier du plugin : fichiers dans wp-content, constante WP_CACHE dans wp-config.php, ou règles dans .htaccess. Le relevé est effectué avant désinstallation.

LiteSpeed Cache et W3 Total Cache modifient ou créent .htaccess sur les trois piles, y compris Nginx, qui ne l’interprète pas. WP Fastest Cache le modifie dans sa variante avec cache activé sur Apache et OpenLiteSpeed. Aucune modification de ce fichier n’est relevée pour Cache Enabler, WP Super Cache et WP-Optimize dans les configurations testées.

Ces observations décrivent les écritures pendant l’utilisation. Elles ne constituent pas un classement de la qualité de désinstallation. Après la commande de désinstallation, l’accueil répond HTTP 200 dans les 33 lignes retenues. Le banc n’inventorie pas ensuite tous les fichiers, réglages et données qui pourraient subsister.

De même, la réponse de la session connectée diffère de la réponse anonyme dans les 17 lignes classées actives. Ce contrôle ciblé ne certifie pas l’isolation des comptes, des paniers ou de toutes les pages privées.

Qu’en faire sur votre site ?

Commencez par les trois vérifications que ce banc rend concrètes :

1. Confirmer le cache prévu pour votre hébergement. Vérifiez sa compatibilité avec l’extension et les réglages nécessaires, en tenant compte d’un éventuel cache déjà fourni par l’hébergeur.
2. Vérifier son fonctionnement sur une page publique. Un indicateur HIT est utile ; l’absence d’en-tête ne suffit pas à conclure à l’absence de cache. Utilisez aussi le diagnostic propre à l’extension. Le testeur d’en-têtes MesPlugins.fr affiche notamment la directive Cache-Control, mais ne relève pas les indicateurs HIT/MISS des plugins.
3. Tester le renouvellement du contenu. Sur une préproduction, publiez puis modifiez un contenu et vérifiez ce qu’un visiteur déconnecté reçoit. Contrôlez aussi vos formulaires et les parcours connectés concernés.

Dans ce banc, Cache Enabler se distingue par les indices relevés sans réglage supplémentaire sur les trois piles ; LiteSpeed Cache par son fonctionnement sur OpenLiteSpeed. Plusieurs autres extensions affichent des médianes faibles une fois leur cache activé. Le choix utile repose ensuite sur votre configuration et sur le bon fonctionnement de vos pages, davantage que sur une milliseconde d’écart.

Annexe — méthode, données et limites

Périmètre de la série

L’analyse retient 33 lignes portant la date du 10 septembre 2026, soit 11 par pile : six configurations par défaut et cinq variantes avec activation explicite du cache. Cache Enabler n’a pas de variante distincte. Les CSV contiennent aussi des lignes d’août, exclues de ces tableaux. La révision éditoriale du 11 septembre n’a pas donné lieu à une nouvelle campagne de mesures.

Le banc prépare le même contenu WordPress, avec une cible de 80 articles et 200 commentaires, sur trois piles en conteneurs. Les versions des six extensions figurent dans le premier tableau. Le rapport de campagne indique PHP 8.3 sur Apache et Nginx, et lsphp 8.4 sur OpenLiteSpeed : les environnements ne diffèrent donc pas uniquement par leur serveur web.

Le fichier Compose conservé référence notamment wordpress:php8.3-apache, wordpress:php8.3-fpm, nginx:alpine, mariadb:11 et litespeedtech/openlitespeed:latest. Des tags flottants ne donnent pas les versions exactes exécutées le jour du test ; aucun manifeste complet des images utilisées n’accompagne les résultats.

Chronométrage et rapports

Les requêtes HTTP utilisent la boucle locale, ports 18401, 18402 et 18403, avec un en-tête Accept contenant text/html. Le script chronomètre une première requête après activation et configuration, puis dix requêtes par défaut. Il arrondit chaque mesure à la milliseconde et ramène la médiane paire à un entier.

La colonne ttfb_froid désigne cette première requête. Elle ne garantit pas un cache totalement froid : aucun état MISS/HIT n’est conservé pour chacune des requêtes chronométrées. ttfb_chaud désigne la médiane suivante, pas un temps de chargement complet.

La colonne rapport divise les deux valeurs entières de la même ligne, avec troncature à une décimale. Exemple : LiteSpeed Cache sur OpenLiteSpeed, par défaut, donne 159 / 1 = 159,0 ; sa variante avec cache activé donne 1 / 1 = 1,0. Ce rapport n’est pas un gain contre un témoin indépendant sans extension. Le script affiche un témoin en console, mais ne le conserve pas dans une colonne des CSV. Aucun multiplicateur de gain contre ce témoin n’est donc présenté ici.

Indices de cache et contrôles fonctionnels

La colonne preuve repose, dans les 33 lignes retenues, sur un en-tête ou sur des fichiers. Le code peut également retenir une péremption prolongée, mais aucune ligne positive de cette série n’utilise ce troisième critère. Un en-tête identifiant un moteur et un en-tête indiquant explicitement HIT n’ont pas la même portée. La présence d’un fichier ne démontre pas son utilisation par une requête donnée.

Après publication d’un article sonde par XML-RPC, le script consulte l’accueil aux paliers 1, 2, 5, 10, 30 et 60 secondes. La valeur enregistrée est le premier palier positif ; - signifie que le contenu n’a pas été vu au dernier contrôle. Ce parcours ne teste pas toutes les méthodes de publication, les modifications d’articles ni toutes les pages du site.

Le contrôle connecté compare les empreintes des réponses après une authentification réelle. Les codes de robots.txt et wp-login.php valent 200 sur les 33 lignes ; cela ne prouve pas l’absence de modification de leur contenu ou de leur comportement. Les écritures de fichiers sont relevées avant désinstallation. Après celle-ci, le seul contrôle conservé est le statut HTTP de l’accueil.

Ce qui limite la comparaison

Un seul site, sans parcours de boutique ni constructeur de pages représentatif, ne décrit pas tous les usages. Les dix mesures brutes, leur dispersion et les ressources de la machine ne sont pas jointes aux CSV. OpenLiteSpeed a fait l’objet de plusieurs reprises. Les différences de PHP, les arrondis et l’absence de répétitions indépendantes documentées limitent les comparaisons entre piles et les classements fins.

Des artefacts ont été corrigés entre les premières passes et la série retenue : en-tête Accept, références de restauration, chemins OpenLiteSpeed, sonde de publication et authentification. Certains commentaires et rapports intermédiaires décrivent un état antérieur. Les CSV datés et le code sont à lire ensemble. Certaines erreurs de commandes sont masquées par le script ; un statut final positif ne valide pas rétroactivement toutes ses étapes.

Ce banc ne mesure ni les Core Web Vitals, ni la tenue sous charge, ni un gain SEO, ni la sécurité de toutes les sessions. Ces questions demanderaient un protocole supplémentaire.

Consulter les sources

Les données et scripts cités correspondent à la révision acd0904 du dépôt public, pour éviter qu’une évolution future du dépôt change la référence de l’article :

• CSV : Apache, Nginx, OpenLiteSpeed. Filtrer serie = 2026-09-10.
• Protocole : mesure.sh, installer.sh, docker-compose.yml.

Le README de cette révision conserve des descriptions antérieures à la série complète. Pour lire les résultats, les conventions de cette annexe précisent la portée effective des colonnes.