Combien de requêtes SQL une page produit-elle sur un site correctement caché ? Sur ce projet, la réponse attendue tournait autour de dix requêtes par page grâce à W3 Total Cache déjà en place. Après l’ajout de Redis Object Cache, censé accélérer encore les choses, le nombre de requêtes a doublé au lieu de baisser, et le temps de génération des pages s’est allongé.
Ce résultat contre-intuitif s’explique par un conflit classique entre deux mécanismes de cache d’objets actifs simultanément : W3 Total Cache intègre son propre cache d’objets, configurable pour utiliser Redis comme backend, et l’extension Redis Object Cache installée séparément fait exactement la même chose, via son propre fichier object-cache.php déposé dans wp-content.
Le symptôme : requêtes dupliquées et lenteur inattendue
Avec Query Monitor activé sur l’environnement de test, le nombre de requêtes MySQL par page affichait presque le double de la normale, et le temps de génération de la page dépassait largement les habitudes du site. Ce genre de régression après l’ajout d’un outil censé accélérer les choses doit toujours faire suspecter un conflit entre deux mécanismes qui font le même travail.
Comprendre le mécanisme du cache d’objets
WordPress dispose nativement d’un cache d’objets en mémoire, valable uniquement pour la durée d’une requête HTTP (non persistant par défaut). Une extension de cache d’objets persistant, comme Redis Object Cache, remplace ce mécanisme par défaut en déposant un fichier object-cache.php à la racine de wp-content, ce fichier étant chargé très tôt dans le cycle de démarrage de WordPress.
Le problème survient quand W3 Total Cache, configuré pour utiliser également Redis comme backend de cache d’objets dans ses propres réglages, tente d’écrire ses propres clés de cache en parallèle de celles gérées par le fichier object-cache.php déposé par l’autre extension. Les deux systèmes finissent par se marcher dessus, invalidant mutuellement leurs entrées respectives plus souvent qu’ils ne les servent depuis le cache.
Vérifier lequel des deux est réellement actif
La commande WP-CLI suivante confirme quel mécanisme de cache d’objets est effectivement chargé :
wp cache type
# Redis (via Redis Object Cache)
# ou
# W3TC (via le module Object Cache de W3 Total Cache)
Il est également possible de vérifier directement la présence et le contenu du fichier concerné :
cat wp-content/object-cache.php | head -5
Le correctif : un seul gestionnaire de cache d’objets
La règle est simple une fois le conflit identifié : un seul système doit gérer le cache d’objets Redis, jamais deux en parallèle. Deux options s’offrent, selon les préférences de configuration déjà en place :
- Désactiver le module « Object Cache » dans les réglages de W3 Total Cache et laisser Redis Object Cache gérer seul le cache d’objets persistant
- Ou désinstaller Redis Object Cache et configurer entièrement le cache d’objets via l’interface native de W3 Total Cache, en pointant vers le même serveur Redis
La première option est généralement préférée quand Redis Object Cache est déjà bien connu de l’équipe, car son interface de diagnostic (statistiques de hits et misses en temps réel) est plus lisible que celle de W3 Total Cache sur ce module précis.
Vérifier après correctif
wp redis status
# Status: Connected
# Hits: 4821, Misses: 213, Ratio: 95.7 %
Un ratio de hits élevé, au-delà de 90 %, confirme que le cache fonctionne correctement une fois le doublon supprimé. Le nombre de requêtes MySQL par page, revérifié avec Query Monitor, doit alors retrouver son niveau initial, voire l’améliorer légèrement par rapport à la situation avant l’ajout de Redis.
Prévention pour la suite
Avant d’ajouter une extension de cache d’objets à un site qui utilise déjà une suite de cache complète comme W3 Total Cache ou WP Rocket, vérifier systématiquement si cette suite gère déjà elle-même le cache d’objets. Ajouter un second outil sans désactiver le premier ne fait jamais gagner en performance.
Ce conflit ne concerne que le cache d’objets, distinct du cache de page HTML géré par ailleurs par ces mêmes extensions : le cache de page continue de fonctionner normalement pendant tout l’incident, ce qui explique pourquoi le problème passe parfois inaperçu plusieurs jours avant d’être identifié.
En résumé
Un site plus lent après l’ajout d’un second cache d’objets révèle presque toujours le même schéma : deux mécanismes redondants qui s’invalident mutuellement plutôt que de coopérer. Vérifier quel fichier object-cache.php est réellement chargé, désactiver le module en doublon dans la suite de cache existante, puis confirmer le ratio de hits Redis après correctif suffit à retrouver, et souvent dépasser, les performances d’avant l’incident.
