Redis pour WordPress : installation, cache objet et tuning complet (2025)

1. Redis et WordPress : à quoi sert le cache objet ?

Par défaut, WordPress interroge la base de données à chaque requête HTTP pour récupérer des informations : articles, options, menus, widgets, sessions, etc. Une partie de ces données est déjà mise en cache en mémoire côté PHP, mais seulement pendant la durée de la requête. Dès qu’une nouvelle requête arrive, tout doit être recalculé.

Redis permet de stocker ces données dans une base clé/valeur en mémoire, persistante entre les requêtes. C’est ce qu’on appelle le cache objet :

• WordPress demande un objet (par exemple, les options du site).
• Si l’objet est déjà dans Redis, il est servi directement depuis la RAM.
• Sinon, WordPress interroge MySQL, puis stocke le résultat dans Redis pour la prochaine fois.

Résultat :

• Moins de requêtes SQL.
• Moins de charge sur MySQL/MariaDB.
• Un back-office plus réactif, surtout sur des sites qui utilisent beaucoup de plugins.

Pour un site simple, Redis est un plus. Pour un parc de sites WordPress ou pour des sites complexes (WooCommerce, membership, LMS, etc.), c’est souvent un élément indispensable de la stack.

2. Installer Redis sur le serveur (Linux)

La plupart des distributions Linux récentes proposent Redis dans leurs dépôts. Voici un exemple d’installation sur une base Debian/Ubuntu (adaptable à d’autres OS) :

2.1. Installation de base

Sur Debian/Ubuntu :

apt update
apt install redis-server

Une fois installé, Redis se lance généralement comme service systemd :

systemctl status redis-server

Vous devriez voir le service en “active (running)”.

2.2. Configuration de base

Le fichier de configuration principal se trouve souvent dans :

/etc/redis/redis.conf

Sur un serveur WordPress, l’objectif est d’avoir une instance Redis :

• qui n’écoute que localement (pour éviter un accès direct depuis Internet),
• avec une consommation mémoire contrôlée,
• avec une persistance adaptée (ou non) à votre usage.

3. Sécuriser Redis : bind, mot de passe, firewall

Redis n’a aucun mécanisme de sécurité par défaut adapté à une exposition Internet. Il doit être strictement limité à des connexions locales ou à un réseau privé.

3.1. Limiter l’écoute à localhost

Dans redis.conf :

bind 127.0.0.1
protected-mode yes

Cela évite que Redis soit accessible directement depuis l’extérieur.

3.2. Ajouter un mot de passe

Vous pouvez ajouter une couche de protection supplémentaire avec :

requirepass mot_de_passe_tres_long_et_complexe

Cela nécessite ensuite une authentification avant de pouvoir envoyer des commandes à Redis.

3.3. Firewall & accès restreint

En plus de la configuration de Redis, il est recommandé de :

• bloquer le port Redis (6379) sur le pare-feu externe (UFW, iptables, etc.),
• n’autoriser que le serveur web (local) à communiquer avec Redis.

Sur un serveur où Redis n’est utilisé que localement, vous pouvez même bloquer totalement les connexions entrantes sur 6379 depuis l’extérieur.

4. Intégrer Redis à WordPress (plugin + wp-config)

Une fois Redis installé et sécurisé, il faut l’intégrer côté WordPress. La manière la plus simple est d’utiliser un plugin de cache objet dédié.

4.1. Choisir un plugin Redis

Les plugins fréquemment utilisés :

• Redis Object Cache (très populaire, maintenu, simple à configurer).
• W3 Total Cache ou autres plugins tout-en-un qui incluent un module Redis.

Pour rester simple et robuste, nous prendrons l’exemple de Redis Object Cache.

4.2. Configuration via wp-config.php

Dans votre wp-config.php, ajoutez :

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );

Si vous avez défini un mot de passe dans redis.conf :

define( 'WP_REDIS_PASSWORD', 'mot_de_passe_tres_long_et_complexe' );

Dans certains environnements, vous pouvez aussi utiliser un socket Unix plutôt qu’un port TCP (plus performant) :

define( 'WP_REDIS_PATH', '/run/redis/redis.sock' );

4.3. Activation du cache objet

Une fois le plugin activé, la plupart du temps :

• vous cliquez sur “Enable Object Cache” dans le panneau Redis,
• une drop-in object-cache.php est installée dans wp-content,
• WordPress commence à utiliser Redis pour les objets mis en cache.

Vous pouvez vérifier que Redis est bien utilisé via la page de statut du plugin, ou en surveillant l’activité sur Redis via la commande redis-cli monitor (uniquement en test, ce mode est très verbeux en production).

5. Stratégies de cache objet et bonnes pratiques

Redis peut apporter un énorme gain, mais mal utilisé, il peut aussi :

• consommer trop de RAM,
• accumuler des clés inutiles,
• garder des données obsolètes si les invalidations sont mal gérées.

5.1. Taille mémoire et politique d’éviction

Dans redis.conf, vous pouvez définir une limite mémoire :

maxmemory 512mb

Et une politique d’éviction, par exemple :

maxmemory-policy allkeys-lru

Ce qui signifie que lorsque la mémoire est pleine, Redis supprimera les clés les moins récemment utilisées pour faire de la place aux nouvelles.

5.2. Ce qu’il ne faut pas mettre dans Redis

Les plugins de cache objet gèrent déjà la plupart des cas, mais en règle générale :

• Évitez de stocker des données trop volumineuses (gros blobs, blobs de logs, etc.).
• Évitez de “forcer” manuellement le cache sur des données rarement utilisées.
• Surveillez les plugins qui abusent des transients.

5.3. Interactions avec le cache page

Redis ne remplace pas le cache de page (HTML généré) ni le CDN. Il vient en complément :

• Le cache de page évite de regénérer le HTML pour les visiteurs non connectés.
• Le cache objet accélère les requêtes côté base pour les pages dynamiques, l’admin, les utilisateurs connectés, les API, etc.
• Le CDN (Cloudflare, par exemple) cache les fichiers statiques en bordure de réseau.

Sur un site qui combine ces trois couches, les gains peuvent être très significatifs.

6. Monitoring & debug de Redis

Pour vérifier que Redis fonctionne correctement et que sa configuration est adaptée, quelques commandes et outils sont très utiles.

6.1. redis-cli info

La commande :

redis-cli info

fournit de nombreuses informations :

• utilisation mémoire,
• nombre de clés,
• hits / misses de cache (selon les stats),
• uptime,
• config actuelle.

6.2. Outils graphiques

Vous pouvez compléter avec :

• Netdata (module Redis),
• Prometheus + exporter Redis,
• Des dashboards Grafana.

L’idée est de repérer :

• si la mémoire allouée est suffisante,
• si le nombre de clés explose sans raison,
• si le taux de cache hits est cohérent avec vos attentes.

7. Redis dans un environnement multi-sites / multi-serveurs

Dans un environnement multi-sites (plusieurs WordPress sur le même serveur) ou multi-serveurs (clusters), Redis devient encore plus intéressant.

7.1. Plusieurs sites sur le même Redis

Vous pouvez utiliser :

• un Redis par serveur, partagé par plusieurs sites,
• ou plusieurs Redis (ports différents) si vous voulez isoler certains clients.

Les plugins Redis sérieux gèrent généralement un préfixe de clé par site, pour éviter les collisions (ex. blog_1:, blog_2: en multisite, ou un hash du domaine).

7.2. Clusters et haute disponibilité

Sur des infrastructures plus avancées, vous pouvez mettre en place :

• Redis Sentinel (failover automatique),
• Redis Cluster (sharding horizontal),
• des architectures avec plusieurs frontaux partageant la même instance Redis.

Pour la majorité des TPE/PME et des freelances, un Redis standalone bien configuré est largement suffisant. Les architectures de haute disponibilité sont surtout nécessaires pour des sites à très fort trafic.

FAQ – Redis & WordPress

Redis remplace-t-il totalement le cache de page WordPress ?

Non. Redis gère le cache objet (données en base), tandis que le cache de page évite de regénérer le HTML pour chaque visiteur. Les deux sont complémentaires et idéalement utilisés ensemble.

Est-ce que Redis est utile pour un petit site vitrine ?

Sur un petit site avec peu de trafic, le gain sera moins spectaculaire, mais il peut tout de même améliorer la réactivité de l’admin, surtout si le thème/plugins sont un peu lourds. Là où Redis devient vraiment intéressant, c’est dès que le trafic ou le nombre de sites augmente.

Combien de mémoire dois-je allouer à Redis ?

Pour un serveur multi-sites, réserver entre 512 Mo et 1 Go à Redis est souvent un bon point de départ. Sur un petit VPS, 256 Mo peuvent suffire. Surveillez cependant l’utilisation réelle et ajustez en conséquence.

Redis est-il dangereux s’il est exposé sur Internet ?

Oui. Redis ne doit jamais être accessible directement depuis Internet. Il doit être lié à 127.0.0.1 ou à un réseau privé, avec un mot de passe fort, et protégé par un pare-feu.

Je vois toujours beaucoup de requêtes SQL dans les logs, Redis ne fonctionne pas ?

Redis ne met pas en cache toutes les requêtes SQL, mais seulement les objets que WordPress décide de stocker (transients, options, résultats de requêtes fréquentes, etc.). Il est normal qu’une partie du trafic continue à passer par MySQL. L’idée est de réduire la charge, pas de la supprimer totalement.

Conclusion : Redis comme brique clé de performance

Redis est l’une des briques les plus efficaces pour améliorer les performances de WordPress, surtout dans un contexte professionnel : plusieurs sites, trafic significatif, plugins gourmands, back-offices très utilisés. En l’installant correctement, en le sécurisant, en l’intégrant via un plugin de cache objet et en le surveillant, vous obtenez un gain réel sur la charge SQL, la réactivité du site et la stabilité globale du serveur.

Combiné aux optimisations décrites dans le guide pilier (architecture serveur, PHP-FPM, MySQL/MariaDB, cache de page, CDN, Cloudflare), Redis devient un élément central de votre stratégie de performance. Il s’intègre naturellement dans un cluster serveur bien pensé, que vous soyez freelance, agence ou TPE/PME avec plusieurs sites à maintenir.