On vend souvent Redis comme une baguette magique pour le LCP (le temps d'affichage du contenu principal). L'object cache persiste ce que WordPress remettrait en base à chaque bootstrap (`wp_options` autoload, objets). Sur un admin lent, un Woo, un site avec beaucoup de requêtes dynamiques, ça se sent. Sur une vitrine déjà en cache de page, le gain visiteur est mince. Cet article sépare object cache et cache de page, dit quand Redis (ou Memcached) vaut la mise en place, et les pièges (mauvaise invalidation, deux caches, objet énorme).
⚡ Deux caches, deux rôles
Le cache de page sert du HTML tout fait au visiteur anonyme. L'object cache garde des objets PHP/MySQL en mémoire. Redis est un bon moteur pour le second. Il peut aussi servir de backend à d'autres choses. Sur WordPress, le drop-in `object-cache.php` est le sujet.
Sans cache de page, Redis n'empêche pas de reconstruire le HTML. Avec un autoload de 3 Mo, Redis évite de le relire en SQL, mais PHP doit encore traiter un gros volume de données. On allège `wp_options` (article alléger WordPress).
🛒 Où je le vois utile
Woo admin, beaucoup de transients, multisite, visites connectées. Vitrine calme déjà cachée : optionnel.
L'hébergement doit fournir Redis (ou Memcached) et le tenir. Un Redis qui swap, on a déplacé le problème.
- Redis disponible, persistance adaptée
- Un seul drop-in
- Purge documentée après mise à jour
- Mesure admin avant / après
⚠️ Pièges
Deux plugins d'object cache. Objets monstrueux (on met en cache des objets trop gros). Oublier que les sessions et le panier ne se cachent pas comme une option. Sérialisation d'objets qui casse après une mise à jour de plugin.
Flush brutal en soldes : tout le monde reconstruit. On vide le cache de façon ciblée.
✅ Vérification
Staging, drop-in, test de l'admin, d'une page produit, du panier. Si le panier ment, on arrête. Voir l'article sur le cache et le tunnel de vente.
Redis / object cache WordPress : un outil de TMA, pas un badge d'hébergeur.
✅ Liste de contrôle avant d'activer Redis
Avant d'activer Redis, j'écris quelles pages sont lentes et pourquoi : requêtes en base, extensions lourdes, hébergement saturé. La mesure qui compte : le temps de réponse du serveur sur les pages qui ne passent pas par le cache, comme le panier ou l'admin.
Sauvegarde restaurable, mesure du temps de réponse avant, accès au serveur à votre nom. Puis l'activation du cache d'objets. Puis 24 à 72 h de suivi (mémoire, temps de réponse, erreurs de panier). Sans cette comparaison, on a ajouté un service, pas prouvé qu'il sert.
- Temps de réponse serveur relevé sur le panier et l'admin
- Copie de test avant d'activer le cache d'objets
- Un changement à la fois, documenté
- Test du panier, de la connexion et des stocks après activation, puis 24 h de suivi de la mémoire
📌 Ce que je refuse sur ce sujet
Je refuse d'activer Redis pour masquer une extension qui lance des centaines de requêtes. Je refuse aussi de le brancher sur un hébergement mutualisé où il n'est pas isolé.
Si la lenteur vient des images, du thème ou de l'hébergement, je vous le dis avant de parler de cache.
Redis n'accélère pas un thème sale. Il cache plus vite le même désordre.
🧭 Questions fréquentes
Faut-il l'installer sans attendre ? Oui si l'administration rame ou si la base est saturée aux heures de pointe. Sinon, on commence par mesurer : un thème lourd ne se règle pas avec un cache d'objets.
Peut-on l'activer sans copie de test ? Sur une vitrine calme, parfois. Sur une boutique, non : un cache qui garde un panier périmé coûte des ventes. Voir Tester un site WordPress en local et en préprod.
Combien de temps ? Une demi-journée si le serveur propose déjà Redis, deux jours s'il faut l'installer et surveiller la mémoire. Un devis « on branche Redis en dix minutes » ne mesure pas le gain réel.
