WP Rocket ou Redis Object Cache – lequel choisir pour optimiser un site WordPress ? La vraie réponse : les deux, mais pas pour les mêmes raisons. J’ai mené un benchmark complet sur juzed.dev – pages publiques ET interface d’administration – pour mesurer l’apport réel de chaque solution. Les résultats révèlent quelque chose d’intéressant sur le fonctionnement interne de l’object cache.
Contexte et stack
Le site tourne sur WordPress FSE, stack Bedrock + Timber/Twig, PHP 8.4, Apache, environnement local DDEV sous Docker. Deux plugins de cache testés :
- WP Rocket – cache full-page, sert du HTML statique directement sans solliciter PHP
- Redis Object Cache 2.7.0 – met en cache les résultats de requêtes BDD en mémoire (Redis 7.4.8, PhpRedis 6.2.0)
La mise en place dans un projet Bedrock est rapide : ajout du plugin via Composer, configuration de WP_REDIS_HOST et WP_REDIS_PORT dans config/application.php, activation du drop-in via wp redis enable. Dix minutes, chrono en main.
Méthodologie
Tests avec Apache Bench sur deux contextes distincts – parce qu’un benchmark uniquement sur les pages publiques cache une partie de la réalité :
- Pages front publiques – 100 requêtes, 5 connexions simultanées, page d’accueil (
/) et liste de projets (/projets/). Quatre scénarios croisés : Rocket actif/inactif × Redis actif/inactif. - Admin WordPress – 50 requêtes, 3 connexions simultanées, sur quatre pages (
edit.php,edit.php?post_type=project,upload.php, dashboard), testées avec un administrateur authentifié via cookie de session réel. WP Rocket est inactif par définition sur l’admin.
Résultats – pages front publiques
| Scénario | Accueil req/s | Accueil ms/req | /projets/ req/s | /projets/ ms/req |
|---|---|---|---|---|
| Rocket + Redis | 82,55 | 60,6 ms | 71,83 | 69,6 ms |
| Rocket seul | 79,17 | 63,2 ms | 85,28 | 58,6 ms |
| Redis seul | 13,65 | 366 ms | 12,08 | 414 ms |
| Aucun cache | 12,84 | 389 ms | 11,62 | 430 ms |
WP Rocket est dominant. Passer de ~12 à ~82 req/s sur la page d’accueil, c’est un facteur ×6. La mécanique est simple : Rocket court-circuite entièrement PHP en servant du HTML pré-généré depuis le disque. Le serveur n’exécute rien, il lit un fichier.
Redis seul n’apporte que +6 à +7% de req/s et réduit le temps de réponse de ~20 ms. Utile, mais sans commune mesure avec le cache full-page. Avec Rocket actif, Redis devient statistiquement anecdotique – les résultats légèrement incohérents entre les deux pages le confirment : on est dans la marge de variabilité normale à ce niveau de performance.
Résultats – admin WordPress
| Page admin | Avec Redis | Sans Redis | Gain |
|---|---|---|---|
| Liste articles (edit.php) | 8,01 req/s / 374 ms | 7,52 req/s / 399 ms | +6,5% / −25 ms |
| Liste projets (edit.php?post_type=project) | 7,96 req/s / 377 ms | 7,46 req/s / 402 ms | +6,7% / −25 ms |
| Médiathèque (upload.php) | 8,67 req/s / 346 ms | 8,07 req/s / 372 ms | +7,4% / −26 ms |
C’est ici que Redis révèle son vrai terrain de jeu – et le tableau révèle quelque chose de plus intéressant que les chiffres bruts.
Le gain est remarquablement constant : ~+7% de débit, ~25 ms de moins par requête, quelle que soit la page admin testée. Liste d’articles, liste de CPT custom, médiathèque – trois contextes très différents en termes de requêtes spécifiques, et pourtant le bénéfice de Redis est quasi identique sur chacun.
Ce que ça révèle : Redis ne cache pas principalement les requêtes propres à chaque page – il cache les données transversales que WordPress charge sur chaque requête admin, quelle que soit la page. Les options WordPress (wp_options), les métadonnées utilisateur, les transients, les capacités et rôles : ces données sont chargées à chaque chargement de page admin, et elles représentent une part significative du coût total. Redis les met en mémoire une fois, les sert ensuite en quelques microsecondes.
Deux outils, deux périmètres
Ce benchmark confirme que WP Rocket et Redis ne se font pas concurrence – ils opèrent à des niveaux différents de la stack :
- WP Rocket – imbattable sur les pages publiques anonymes. Il supprime l’exécution PHP, pas juste les requêtes BDD. Priorité absolue sur tout site WordPress à trafic public.
- Redis Object Cache – constant et fiable partout où PHP s’exécute réellement : admin, pages exclues du cache Rocket, contenus dynamiques, utilisateurs connectés.
Quand Redis vaut vraiment le coup en production
- Sites avec espace membres – WP Rocket n’agit pas sur les utilisateurs connectés. Redis prend le relais sur toutes leurs pages.
- E-commerce WooCommerce – panier, compte, tunnel de commande : pages majoritairement exclues du cache full-page.
- Bases de données volumineuses – plus la BDD est grande, plus les requêtes sont coûteuses, plus Redis amortit le coût sur les données transversales.
- Toute équipe qui travaille dans l’admin – 25 ms par requête, multiplié par des centaines d’actions par jour sur un site actif, ça se ressent.
- Sites à fort trafic avec pages dynamiques – résultats de recherche, archives filtrées, pages avec paramètres d’URL : autant de pages que Rocket exclut et que Redis optimise.
Conclusion
Sur juzed.dev – site entièrement public sans espace connecté – WP Rocket fait l’essentiel du travail en production. Redis apporte un gain constant sur l’admin et une couverture sur les pages non cachées.
La mise en place dans un projet Bedrock est suffisamment simple pour ne pas hésiter. Le coût d’entrée est minimal, la couverture est complète.
Mon setup final : Rocket + Redis, les deux actifs. Pas parce que la combinaison est spectaculaire sur ce site – mais parce que chacun couvre un périmètre que l’autre ne touche pas.
Prochaines étapes : je referai ces tests sur un projet Elementor, et sur un projet avec une partie connectée en front. Les résultats devraient être très différents – à suivre.
Stack : WordPress FSE · Bedrock · Timber/Twig · WP Rocket · Redis Object Cache 2.7.0 · Redis 7.4.8 · PhpRedis 6.2.0 · Apache Bench · DDEV · MariaDB