Un Redis Object Cache est rentable pour les requêtes auxquelles un Page Cache ne peut pas répondre, surtout pour les utilisateurs connectés, les paniers et l’administration. Il conserve en mémoire les résultats des requêtes de base de données de WordPress, de sorte que les requêtes suivantes les évitent. Un petit site dont toutes les pages proviennent d’un Page Cache y gagne peu.
Que fait un cache d’objets dans WordPress ?
WordPress intègre un cache d’objets qui, par défaut, ne dure que le temps d’une requête. Les options, les articles, les termes et les résultats de nombreuses requêtes d’extensions sont chargés dans la mémoire de PHP, puis éliminés une fois la page terminée.
Un drop-in dans wp-content/object-cache.php remplace ce cache et stocke les mêmes données dans un serveur tel que Redis. Chaque requête peut alors réutiliser ce que les précédentes ont chargé, et la base de données reçoit moins de requêtes.
Un Page Cache agit un niveau plus haut. Il stocke le HTML fini et répond avec peu de PHP, voire sans PHP. Avec un cache d’objets, WordPress construit toujours la page, mais avec moins d’allers-retours vers la base de données. Un site peut utiliser les deux.
Quand est-il rentable ?
| Requête ou site | Effet | Raison |
|---|---|---|
| Requête ou site : Pages du panier, de la commande et du compte | Effet : Rentable | Raison : Elles ne peuvent pas provenir d’un Page Cache et lisent à chaque requête des données de produits, de session et d’utilisateur |
| Requête ou site : Utilisateurs connectés et administration | Effet : Rentable | Raison : Les rédacteurs, les gérants de boutique et les membres n’obtiennent aucun succès du Page Cache |
| Requête ou site : Boutiques et sites multilingues | Effet : Rentable | Raison : WooCommerce, WPML et WCML répètent des recherches de produits, de termes, de traductions et de devises |
| Requête ou site : Pages avec de nombreuses requêtes | Effet : Rentable | Raison : Les grands menus, les filtres, les articles associés et les constructeurs de pages exécutent des requêtes auxquelles le cache peut répondre |
| Requête ou site : Petit site avec des visiteurs anonymes | Effet : Effet faible | Raison : Le Page Cache répond à presque toutes les requêtes |
| Requête ou site : Recherche en texte libre | Effet : Effet faible | Raison : Chaque terme recherché est une nouvelle requête, donc peu de choses sont réutilisées |
WordPress donne lui-même un signal. Depuis la version 6.1, Santé du site suggère un cache d’objets persistant lorsqu’un site dépasse certains seuils, par exemple 1 000 articles, termes, utilisateurs, commentaires ou options, ou 500 options chargées automatiquement.
De quoi ai-je besoin ?
- Un serveur Redis sur la même machine, ou accessible via un réseau interne ou TLS.
- Un client PHP. phpredis est une extension compilée, Predis une bibliothèque PHP. Les extensions WordPress n’acceptent pas toutes les mêmes.
- Une extension qui installe le drop-in.
- Une limite de mémoire dans Redis et une politique d’éviction (voir plus bas).
Trois commandes montrent ce dont un serveur dispose déjà. wp cache type affiche Default tant qu’aucun cache persistant n’est actif.
php -m | grep -i redis
redis-cli ping
wp cache typeQuels pièges faut-il connaître ?
Une base Redis partagée
Certains hébergeurs attribuent la même base Redis à plusieurs sites. Sans préfixe de clé, deux sites WordPress écrasent mutuellement leurs options. Donnez à chaque site son propre préfixe dans wp-config.php ; le nom de la constante dépend de l’extension. La documentation de Redis déconseille les bases numérotées pour des applications sans rapport entre elles.
Vidages du cache
WordPress et de nombreuses extensions vident le cache d’objets après les mises à jour et les imports. FLUSHDB vide toute la base, y compris les données de tous les autres qui s’y trouvent. Sur une base partagée, un vidage ne doit supprimer que ses propres clés, ce qui prend plus de temps. Une base dédiée évite le problème.
Limite de mémoire et éviction
Par défaut, Redis sur un système 64 bits n’a pas de limite de mémoire. Lorsqu’une limite est définie, maxmemory-policy détermine ce qui se passe quand elle est atteinte. Avec allkeys-lru, Redis supprime les clés les moins récemment utilisées et le cache continue de fonctionner. Avec noeviction, la valeur par défaut de Redis, les lectures continuent et les nouvelles écritures échouent.
redis-cli CONFIG GET maxmemory
redis-cli CONFIG GET maxmemory-policyPannes
Si Redis se bloque, un drop-in qui attend le délai d’expiration à chaque appel au cache rend une page comportant des centaines d’appels bien plus lente qu’un site sans cache. Vérifiez que votre extension cesse d’utiliser Redis après le premier appel échoué.
Redis peut aussi redémarrer avec des valeurs qui ont changé dans la base de données pendant la panne. Le cache doit alors être vidé une fois.
Comment savoir si cela fonctionne ?
Redis compte les succès et les échecs. Le taux de succès correspond à keyspace_hits divisé par la somme de keyspace_hits et de keyspace_misses. Une valeur croissante de evicted_keys signifie que la limite de mémoire est trop basse pour le site.
redis-cli INFO stats | grep -E "keyspace_|evicted_keys"Un taux de succès élevé ne prouve pas grand-chose à lui seul. Mesurez les requêtes de base de données et le délai jusqu’au premier octet (TTFB) d’une page non mise en cache, avec et sans le cache. Query Monitor affiche les requêtes par requête HTTP.
Comment CachePilot traite-t-il ces points ?
CachePilot est l’extension dont traite ce site. Ses réponses aux pièges ci-dessus :
- Bases partagées. Les clés portent un préfixe. Si la configuration trouve des clés d’une autre application, le vidage reste limité à ce préfixe.
- Pannes. Après une erreur de connexion, le drop-in ignore Redis pendant 30 secondes et vide le cache une fois lorsque Redis revient.
- Allers-retours. SMEMBERS lit la liste des clés qu’une page utilise, MGET charge leurs valeurs. Sur une boutique en production en novembre 2026, cela a fait passer les commandes Redis d’une page de boutique non mise en cache de 691 à 61. Le temps serveur côté front-end était inférieur de 10 à 15 % à celui de Redis Object Cache 3.0.0 (méthode).
La page du cache d’objets décrit le drop-in en détail.
Sources
- Référence développeur WordPress, WP_Object_Cache : non persistant par défaut, remplacement via un drop-in.
- Référence développeur WordPress, contrôle Santé du site pour un cache d’objets : seuils de Santé du site.
- WP-CLI, wp cache type.
- Documentation de Redis, éviction des clés : maxmemory, politiques, taux de succès d’après INFO stats.
- Documentation de Redis, SELECT : bases numérotées.
- phpredis et Predis.
- object-cache.php et Setup.php (src/Autopilot) de l’extension : gestion des pannes, prélecture et détection des bases partagées.
