On entend parfois que Redis Object Cache et WP Rocket font doublon. Spoiler : non. Après le benchmark Apache Bench sur juzed.dev et la mise en prod, j’ai refait les tests sur un projet client en local – stack Bedrock + Timber/Twig, PHP 8.4, Apache, DDEV. Des mesures curl plutôt qu’Apache Bench cette fois, pour avoir les temps de réponse réels page par page.
Setup et méthode
Quatre configurations testées en matrice :
| Config | Redis Object Cache | WP Rocket |
|---|---|---|
| C1 | ✅ ON | ✅ ON |
| C2 | ✅ ON | ❌ OFF |
| C3 | ❌ OFF | ✅ ON |
| C4 | ❌ OFF | ❌ OFF |
Pages testées à chaque fois : admin (edit.php, upload.php), recherche (/?s=a), et homepage en deux passes – premier hit à froid, deuxième hit cache chaud. Moyennes sur 3 mesures curl par URL.
Les chiffres
| Page | C1 Redis+Rocket | C2 Redis seul | C3 Rocket seul | C4 Rien |
|---|---|---|---|---|
| Admin edit.php | 0,127s | 0,084s | 0,134s | 0,085s |
| Admin upload.php | 0,111s | 0,074s | 0,131s | 0,080s |
| Recherche /?s=a | 0,272s | 0,222s | 0,307s | 0,261s |
| Homepage 1er hit | 0,497s | 0,210s | 0,535s | 0,249s |
| Homepage cache chaud | 0,031s | 0,209s | 0,031s | ~0,250s |
Quelques lectures directes : sur le cache chaud (2ème hit homepage), C1 et C3 sont ex-aequo à 31ms. Redis n’apporte rien ici – WP Rocket a déjà tout court-circuité. Sur l’admin en revanche, C2 (Redis seul) est le plus rapide, devant même C4 (rien) : 84ms contre 85ms. Et avec Rocket actif, l’admin est systématiquement plus lent qu’avec Redis seul.
Ce que ça révèle
WP Rocket ne cache pas via Apache dans cette stack
Dans un setup Bedrock, WP Rocket génère bien ses fichiers HTML dans web/app/cache/wp-rocket/ – mais c’est advanced-cache.php (un dropin WordPress) qui les sert, pas Apache directement. Ce dropin s’exécute très tôt dans le bootstrap PHP, trouve le fichier cache, appelle readfile() puis exit. WordPress ne se charge jamais vraiment. D’où les 31ms.
Conséquence : WP Rocket n’a aucun effet sur les pages qui passent toujours par PHP – admin, pages exclues du cache, résultats de recherche.
WP Rocket ralentit légèrement l’admin
C’est le résultat le plus contre-intuitif du tableau : avec Rocket actif (C1), l’admin est ~50ms plus lent qu’avec Redis seul (C2). WP Rocket enregistre des hooks sur l’admin et charge davantage d’objets en object cache – overhead visible en local, négligeable en production sur un vrai serveur. Mais ça confirme que Rocket n’a rien à faire sur l’admin.
Le premier hit avec Rocket est toujours plus lent
~500ms contre ~250ms sans Rocket. Normal : Rocket doit générer ET écrire le fichier HTML sur disque en plus de servir la page. À partir du deuxième hit, le rapport s’inverse massivement – 31ms contre 250ms. Le coût d’entrée est réel, le gain est massif.
Redis aide même sur la recherche
WP Rocket n’intervient jamais sur /?s=a – par design, les résultats de recherche sont exclus du cache fichier. Redis aide quand même : 222ms en C2 contre 261ms en C4, soit ~40ms de moins. Pas spectaculaire, mais constant – et ça se cumule sur une session de navigation.
Deux caches, deux périmètres
La lecture du tableau est claire :
- WP Rocket = cache de page complète (HTML sur disque). Efficace uniquement sur les pages anonymes non exclues, à partir du 2ème hit. ×6 sur les perfs front.
- Redis Object Cache = cache d’objets PHP (requêtes BDD, options, transients). Efficace sur toutes les pages, y compris l’admin et les pages exclues du cache fichier.
Ils ne font pas doublon. Les angles morts de l’un sont couverts par l’autre. C1 – Redis + Rocket actifs – est la configuration optimale : Rocket domine sur le front public, Redis couvre tout le reste.
Stack : WordPress · Bedrock · Timber/Twig · WP Rocket · Redis Object Cache 2.7.0 · PHP 8.4 · Apache · DDEV · curl