Redis pour WordPress : est-ce utile ?

Le problème à résoudre

WordPress possède un cache objet pour la durée d’une requête. Redis permet de conserver certains objets entre les requêtes et peut réduire les lectures répétées en base.

Le gain est important sur des sites dynamiques ou très sollicités, mais parfois faible sur une vitrine déjà entièrement servie par cache de page. Redis ajoute aussi un service à surveiller.

Reconnaître les bons signaux

Signal observé	Interprétation probable	Premier contrôle
Hit rate faible	Objets peu réutilisés ou cache mal ciblé	Observer groupes et clés
Évictions fréquentes	Mémoire insuffisante ou politique inadaptée	Mesurer used_memory
Données croisées entre sites	Préfixe ou base partagée	Isoler les clés

Les notions à maîtriser

Le cache objet ne remplace pas le cache de page : il accélère la construction dynamique.
Une politique d’éviction mal choisie peut supprimer des données attendues par d’autres usages.
Chaque site doit utiliser un préfixe unique, voire une instance séparée selon le risque.
Une panne Redis doit être gérée proprement pour éviter une indisponibilité WordPress.

Méthode de diagnostic

1. Mesurer requêtes SQL et temps PHP avant activation.

2. Vérifier mémoire, persistance requise et autres applications sur Redis.

3. Activer un connecteur maintenu avec préfixe unique.

4. Comparer hit rate, évictions, TTFB dynamique et charge SQL.

Plan d’action recommandé

Réserver une mémoire maximale et une politique adaptée au cache.
Restreindre Redis au réseau local ou à une authentification forte.
Exclure les groupes qui ne doivent pas persister si nécessaire.
Tester le comportement lorsque Redis est arrêté.
Documenter la purge lors d’un déploiement ou changement majeur.

Observer Redis sans vider le cache

Ces commandes lisent les métriques générales. Utilisez l’adresse locale ou le socket prévu et ne publiez jamais les informations d’authentification.

redis-cli INFO memory
redis-cli INFO stats | grep -E 'keyspace_hits|keyspace_misses|evicted_keys'
redis-cli INFO keyspace

Calculez le taux de succès sur une période représentative. KEYS * est à éviter en production sur une base importante ; il peut bloquer l’instance.

Erreurs fréquentes à éviter

Exposer Redis directement à Internet.
Partager le même préfixe entre production et préproduction.
Promettre un gain sans mesurer les requêtes évitées.

Indicateurs à suivre

Indicateur	Repère	Pourquoi le suivre
Hit rate	Élevé après chauffe	Mesure la réutilisation
Evicted keys	0 en régime normal	Signale le manque mémoire
Temps SQL	En baisse sur pages dynamiques	Valide le bénéfice

Checklist avant validation

Une mesure de référence est conservée.
Le changement est testé hors production lorsque c’est possible.
Une sauvegarde ou un retour arrière est disponible.
Les dépendances web, e-mail et DNS ont été contrôlées.
Les journaux et alertes sont surveillés après intervention.
Le résultat est documenté avec date et responsable.

Questions fréquentes

Redis accélère-t-il WooCommerce ?

Il peut aider les lectures répétées, mais le panier et les extensions doivent être testés.

Faut-il activer la persistance ?

Pour un cache pur, elle n’est pas toujours nécessaire ; cela dépend des autres usages de l’instance.

Comment purger ?

Via le connecteur WordPress ou un préfixe dédié, sans vider les données d’autres applications.

Sources techniques

Pour vérifier les règles et approfondir le sujet :

Redis est-il pertinent pour votre WordPress ?

Le cache objet doit être décidé à partir du trafic dynamique, des requêtes SQL et de la capacité à exploiter Redis.

Voir l’accompagnement WordPress