# Installer et configurer Redis comme cache d’objets pour WordPress

> Tutoriel complet pour brancher Redis sur WordPress en cache d'objets persistant : extension PHP, plugin, wp-config.php et vérification avec Query Monitor.

- Auteur : Clément Hadrot
- Publié le : 2020-11-18
- Mis à jour le : 2020-11-18
- Catégorie : Performance
- URL : https://wpmoderne.dev.wordpress-developpement.fr/performance/redis-object-cache-wordpress-configuration/

## L’essentiel

- Le cache d'objets par défaut de WordPress ne survit pas à la requête
- Redis rend ce cache persistant entre les requêtes et entre les visiteurs
- Query Monitor permet de vérifier le taux de succès en conditions réelles

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
```

> L'essentiel à retenir : Le cache d'objets par défaut de WordPress ne survit pas à la requête ; Redis rend ce cache persistant entre les requêtes et entre les visiteurs ; Query Monitor permet de vérifier le taux de succès en conditions réelles

## 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 256mb` par exemple) avec une politique d'éviction adaptée comme `maxmemory-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_DATABASE` ou 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.