WordPress dispose d’un cache d’objets depuis toujours, mais peu de développeurs réalisent à quel point il est limité par défaut. Sans extension de persistance, ce cache vit et meurt avec chaque requête HTTP : les données mises en cache au début du chargement d’une page sont perdues à la fin de cette même page, et la requête suivante repart de zéro. Autant dire que l’essentiel du bénéfice théorique du cache d’objets s’évapore.
Redis change complètement la donne. Ce serveur de stockage clé-valeur en mémoire, déjà bien installé dans l’écosystème PHP, permet de rendre ce cache persistant : les résultats de requêtes coûteuses, les options chargées à l’autoload, les métadonnées de taxonomies, tout peut rester en mémoire d’une visite à l’autre. Sur les sites à fort trafic ou aux requêtes complexes (WooCommerce, multisite, recherches personnalisées), le gain est spectaculaire.
Pourquoi un cache d’objets persistant change tout
Chaque affichage d’une page WordPress déclenche des dizaines, parfois des centaines de requêtes SQL : récupération de l’article, de ses métadonnées, des taxonomies associées, des widgets de la sidebar, des réglages du thème stockés dans wp_options. Beaucoup de ces données changent rarement. Sans cache persistant, elles sont pourtant recalculées à chaque requête HTTP, par chaque visiteur, encore et encore.
Avec Redis en cache d’objets persistant, ces résultats restent en mémoire vive entre les requêtes. La deuxième visite sur une page, et toutes les suivantes, n’ont plus besoin d’interroger MySQL pour les mêmes données : elles les récupèrent directement depuis Redis, en quelques microsecondes plutôt qu’en millisecondes.
Installer Redis et l’extension PHP
Sur un serveur Debian ou Ubuntu, l’installation du serveur Redis lui-même est directe :
sudo apt update
sudo apt install redis-server
sudo systemctl enable redis-server
sudo systemctl start redis-server
Il faut ensuite l’extension PHP redis (aussi appelée phpredis), qui permet à PHP de communiquer avec le serveur Redis. Selon la version de PHP installée :
sudo apt install php7.4-redis
sudo systemctl restart php7.4-fpm
Un rapide test permet de vérifier que tout communique correctement :
php -m | grep redis
redis-cli ping
# doit répondre : PONG
Configurer WordPress : plugin et wp-config.php
Côté WordPress, l’extension la plus utilisée est Redis Object Cache, développée par Till Krüss. Une fois installée et activée depuis le tableau de bord, il reste une étape essentielle : renseigner les constantes de connexion dans wp-config.php, avant la ligne /* That's all, stop editing! */.
define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_TIMEOUT', 1 );
define( 'WP_REDIS_READ_TIMEOUT', 1 );
define( 'WP_CACHE', true );
L’étape suivante se fait depuis Réglages > Redis dans l’administration WordPress : un bouton « Enable Object Cache » copie le fichier object-cache.php fourni par le plugin dans le répertoire wp-content/. C’est ce fichier, appelé un drop-in, qui remplace silencieusement le cache d’objets non persistant de WordPress par des appels à Redis.
Sur un site multisite, pensez également à définir WP_REDIS_SELECTIVE_FLUSH à true, pour que la purge du cache d’un site du réseau ne vide pas celui de tous les autres.
Vérifier le fonctionnement avec Query Monitor
Une fois activé, encore faut-il s’assurer que Redis travaille réellement. L’extension Query Monitor est l’outil de référence pour ça : une fois installée, elle ajoute un panneau « Object Cache » dans la barre d’administration, qui affiche en temps réel :
- le nombre de lectures (gets) et d’écritures (sets) effectuées sur le cache pour la page en cours ;
- le taux de succès (hit ratio), c’est-à-dire la proportion de lectures qui ont trouvé une donnée déjà en cache ;
- la taille approximative des données transférées.
Un taux de succès qui reste obstinément à zéro après plusieurs rechargements de page signale presque toujours un problème de connexion entre PHP et Redis, ou un fichier object-cache.php mal copié. Un taux qui grimpe progressivement au fil des visites est le signe que tout fonctionne comme prévu.
Bonnes pratiques et pièges à éviter
Quelques points de vigilance à connaître avant de considérer l’installation comme terminée :
- Définissez une limite mémoire pour Redis dans
redis.conf(maxmemory 256mbpar exemple) avec une politique d’éviction adaptée commemaxmemory-policy allkeys-lru, pour éviter que Redis ne consomme toute la RAM du serveur. - Sur un serveur mutualisé hébergeant plusieurs sites WordPress, utilisez
WP_REDIS_DATABASEou un préfixe de clés distinct par site pour éviter les collisions de cache entre installations. - Redis stocke tout en mémoire vive : sans persistance disque configurée (RDB ou AOF), un redémarrage du service vide entièrement le cache, ce qui est généralement sans conséquence puisqu’il se reconstruit automatiquement à l’usage.
Ne confondez pas cache d’objets et cache de page. Redis accélère le traitement PHP et les requêtes SQL, mais un visiteur anonyme continuera de déclencher l’exécution de WordPress à chaque visite. Combiné à un cache de page comme fastcgi_cache, le gain est cumulatif et non redondant.
En résumé
Configurer Redis comme cache d’objets persistant est l’une des optimisations les plus rentables pour un site WordPress dont la charge dépasse le simple blog personnel. L’installation ne prend qu’une poignée de commandes, la configuration WordPress se limite à quelques constantes, et Query Monitor offre une vérification immédiate et fiable. Le résultat : un site nettement moins gourmand en requêtes MySQL, et une marge de manœuvre bien plus confortable en cas de pic de trafic.
