Configurer Redis comme cache pour WordPress

Credit : Logo officiel

Configurer Redis comme cache pour WordPress

Dylan D. — Agent Support Technique Serveur WordPress 1819 mots 10 min de lecture

Redis sur WordPress, le client qui croit qu'on a change de serveur

Mardi 18h, ticket priorite haute. Le site d'un client tournait a 4,2 secondes par page sur la home, 6 secondes sur les pages produits, et le TTFB partait en sucette des qu'on depassait 30 visiteurs en simultane. La base MariaDB tournait a 80% CPU pour rien, juste a recalculer les memes options WordPress a chaque requete. Classique. J'ai installe Redis, branche le plugin Object Cache, et trente minutes plus tard la home repondait en 1,2 seconde. Le client m'a appele le lendemain en pensant que j'avais migre son site sur un VPS plus puissant.

C'est l'effet Redis bien configure : une couche memoire entre PHP et la base de donnees qui evite de retaper MySQL pour des donnees qui ne changent pas trois fois par seconde. Sur un WordPress moyen avec une trentaine de plugins, on parle de 200 a 600 requetes SQL par chargement de page. Avec Redis Object Cache active, on passe a 20-40 requetes. Le reste sort de la RAM en quelques microsecondes.

Dans ce guide je couvre l'installation sur Debian 12, la securisation, l'integration avec PHP 8.2 et WordPress, le monitoring quotidien et les pieges qui font perdre des heures. C'est exactement la procedure que j'applique sur les serveurs IONOS que je gere.

Installer Redis sur Debian/Ubuntu

Redis est dans les depots officiels, pas besoin de PPA exotique. Sur Debian 12 et Ubuntu 22.04/24.04 vous obtenez Redis 7.x ce qui est parfait pour WordPress.

sudo apt update
sudo apt install redis-server

# Verifier le service
sudo systemctl status redis-server

# Tester la connexion
redis-cli ping
# PONG

Si vous obtenez PONG, Redis tourne et ecoute. Si la commande renvoie Could not connect to Redis at 127.0.0.1:6379, le service est mort. Allez voir les logs :

sudo journalctl -u redis-server -n 50 --no-pager
sudo tail -50 /var/log/redis/redis-server.log

Dans 90% des cas c'est un probleme de permissions sur /var/lib/redis ou un port deja occupe par un autre service. Verifiez avec sudo ss -tlnp | grep 6379.

Verifier la version installee

redis-server --version
# Redis server v=7.0.15 sha=00000000 ...

A partir de Redis 7, vous beneficiez du support natif des fonctions ACL et de meilleures perfs sur les structures de donnees. C'est ce qu'il vous faut pour 2026.

Securiser l'instance Redis

Redis ecoute par defaut uniquement sur 127.0.0.1, ce qui est correct pour un usage local sur le meme serveur que WordPress. Mais on va quand meme ajouter un mot de passe, limiter la memoire et configurer la politique d'eviction. Sans ca, Redis peut bouffer toute votre RAM et faire crasher PHP-FPM.

sudo nano /etc/redis/redis.conf

Les lignes a verifier ou modifier :

bind 127.0.0.1 ::1
protected-mode yes
requirepass VotreMotDePasseRedis2026Solide
maxmemory 256mb
maxmemory-policy allkeys-lru
appendonly no
save ""

Quelques explications concretes. bind 127.0.0.1 interdit les connexions depuis l'exterieur, c'est un must si vous n'avez pas un cluster Redis dedie. requirepass ajoute un mot de passe meme en local, ca evite qu'un autre process sur le serveur lise vos donnees de cache. maxmemory-policy allkeys-lru indique a Redis qu'il peut evincer les cles les moins recemment utilisees quand la limite est atteinte. Sans cette directive, Redis refuse les nouvelles ecritures et votre site retombe sur MySQL pour tout, donc Redis devient inutile voire pire qu'inutile (overhead pour rien).

Les deux dernieres lignes desactivent la persistance disque. Pour un cache d'objets WordPress, on s'en fout que les donnees survivent a un redemarrage, on les regenere depuis MySQL si besoin. Ca economise des I/O disque et des risques de freeze pendant les snapshots.

sudo systemctl restart redis-server
redis-cli -a VotreMotDePasseRedis2026Solide ping

Installer l'extension PHP redis

L'extension PHP phpredis est compilee en C, c'est la version la plus rapide. Evitez les implementations PHP pures comme Predis sauf cas tres particulier.

sudo apt install php-redis

# Adaptez la version PHP a la votre
sudo systemctl restart php8.2-fpm

# Verifier que l'extension est chargee
php -m | grep redis
# redis

Si vous tournez plusieurs versions de PHP, installez bien la version qui correspond a votre pool actif :

sudo apt install php8.2-redis php8.3-redis

Verifiez aussi via phpinfo si vous avez un doute. Une page test rapide :

<?php phpinfo(); // chercher la section "redis"

Configurer wp-config.php

Ajoutez ces constantes dans wp-config.php, avant la ligne /* That's all, stop editing! */. C'est important, sinon WordPress charge ses propres defaults avant de voir vos directives.

/** Redis Object Cache */
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_PASSWORD', 'VotreMotDePasseRedis2026Solide');
define('WP_REDIS_DATABASE', 0);
define('WP_REDIS_PREFIX', 'wp_monsite_');
define('WP_REDIS_TIMEOUT', 1);
define('WP_REDIS_READ_TIMEOUT', 1);
define('WP_REDIS_MAXTTL', 86400);

Le WP_REDIS_PREFIX est crucial si vous hebergez plusieurs WordPress sur le meme Redis. Sans prefixe, les caches se telescopent et vous obtenez des comportements bizarres : le menu d'un site qui apparait sur l'autre, des options qui se melangent. J'ai mis trois heures a debugger ce genre de truc une fois, plus jamais.

WP_REDIS_MAXTTL definit une duree de vie max pour toutes les cles, je mets 86400 (24h) pour forcer un rafraichissement quotidien meme sur les cles eternelles.

Si vous gerez plusieurs sites, attribuez plutot une base differente a chacun :

// Site 1
define('WP_REDIS_DATABASE', 0);
// Site 2
define('WP_REDIS_DATABASE', 1);

Redis supporte 16 bases (0 a 15) par defaut, ce qui couvre largement la plupart des configs.

Activer le plugin Redis Object Cache

Le plugin de reference est Redis Object Cache par Till Kruss. C'est celui que j'utilise sur tous mes deploiements, gratuit et open source.

cd /var/www/monsite
wp plugin install redis-cache --activate
wp redis enable

La derniere commande cree le fichier wp-content/object-cache.php qui est le drop-in qui intercepte toutes les operations de cache WordPress. Sans ce drop-in, le plugin ne fait rien.

Depuis le back-office : Reglages > Redis. Vous devriez voir :

Si un de ces trois points est rouge, regardez le diagnostic en bas de page. Erreur la plus frequente : mot de passe Redis incorrect dans wp-config.php.

Verifier que le cache fonctionne

Pas confiance aveugle, on verifie. Connectez-vous a Redis et regardez ce qui se passe quand vous chargez une page :

redis-cli -a VotreMotDePasseRedis2026Solide

# Lister les cles WordPress
KEYS wp_monsite_*

# Compter le nombre de cles
DBSIZE

# Stats
INFO stats

# Surveiller en temps reel les operations
MONITOR

Dans une autre fenetre, chargez votre site dans un navigateur. Vous devriez voir defiler les GET et SET dans la commande MONITOR. C'est satisfaisant, presque hypnotique.

Le ratio qui compte vraiment c'est le hit ratio. Recuperez les stats :

redis-cli -a VotreMotDePasseRedis2026Solide INFO stats | grep -E 'hit|miss|evict'

Resultat type apres une journee de trafic :

keyspace_hits:145832
keyspace_misses:12045
evicted_keys:0

Hit ratio = hits / (hits + misses) = 145832 / 157877 = 92,4%. Au-dessus de 90% c'est bon. En dessous de 80% il y a un probleme : soit maxmemory trop faible et Redis evince trop souvent, soit votre code WordPress fait trop de cache busts (souvent un plugin mal code qui flush le cache a la moindre action).

Optimiser la memoire et les serializers

La quantite de memoire allouee depend de votre trafic. Mes regles empiriques apres avoir gere une cinquantaine de WordPress :

# Petit site (< 10k pages vues/mois)
maxmemory 128mb

# Site moyen (10k-100k pages vues/mois)
maxmemory 256mb

# Site important (100k-500k pages vues/mois)
maxmemory 512mb

# Gros site (500k+ pages vues/mois)
maxmemory 1gb

Pour gagner encore en perf, installez igbinary et lzf. Igbinary serialize les donnees PHP plus efficacement que la serialisation native, lzf compresse a la volee.

sudo apt install php-igbinary php-lzf
sudo systemctl restart php8.2-fpm

Dans wp-config.php :

define('WP_REDIS_SERIALIZER', 'igbinary');
define('WP_REDIS_COMPRESSION', 'lzf');
define('WP_REDIS_IGNORED_GROUPS', ['counts', 'plugins', 'themes']);

Le WP_REDIS_IGNORED_GROUPS exclut certains groupes du cache. Les plugins et themes sont rarement modifies en runtime donc le cache n'a pas d'interet, et les counts (nombre de commentaires par exemple) doivent rester frais.

Combiner avec un cache de page

Redis Object Cache acce le PHP, mais il execute toujours PHP. Pour les pages statiques (articles de blog, pages institutionnelles), ajoutez un cache de page au-dessus. Deux options :

Nginx FastCGI Cache (le plus rapide, c'est ce que je preconise) :

fastcgi_cache_path /var/cache/nginx/fastcgi levels=1:2 keys_zone=WORDPRESS:100m max_size=1g inactive=60m use_temp_path=off;

server {
    set $skip_cache 0;
    if ($request_method = POST) { set $skip_cache 1; }
    if ($query_string != "") { set $skip_cache 1; }
    if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|index.php") { set $skip_cache 1; }
    if ($http_cookie ~* "comment_author|wordpress_logged_in|wp-postpass") { set $skip_cache 1; }

    location ~ \.php$ {
        fastcgi_cache WORDPRESS;
        fastcgi_cache_valid 200 60m;
        fastcgi_cache_bypass $skip_cache;
        fastcgi_no_cache $skip_cache;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

WP Super Cache ou WP Rocket si vous preferez gerer ca via plugin. Plus simple a configurer mais legerement plus lent.

Erreurs courantes et leur fix

Error establishing a Redis connection. Le plus frequent. Ouvrez wp-config.php et verifiez le mot de passe entre les guillemets, sans espace ni caractere bizarre. Testez en ligne de commande : redis-cli -a VotreMotDePasse ping. Si ca repond PONG, le probleme est dans wp-config.php.

Redis connection refused apres reboot. Le service ne demarre pas au boot. Activez-le :

sudo systemctl enable redis-server
sudo systemctl is-enabled redis-server
# enabled

maxmemory atteint en permanence, hit ratio qui chute. Augmentez maxmemory ou nettoyez les cles inutiles. Verifiez aussi qu'aucun plugin ne stocke des trucs enormes dans le cache (j'ai vu un plugin de stats stocker des arrays de 50 Mo, ca tue Redis en 2 minutes).

Pages qui ne se mettent pas a jour apres modification. Le cache n'est pas invalide proprement. Forcez un flush :

wp redis flush
# ou
redis-cli -a VotreMotDePasse FLUSHDB

Le plugin affiche "Drop-in not valid". Le fichier wp-content/object-cache.php est obsolete. Desactivez-reactivez le plugin, ou supprimez le fichier et relancez wp redis enable.

Pour aller plus loin

Conclusion : Redis, l'investissement qui paye en deux heures

Deux heures de configuration, dix annees de pages chargees plus vite. Redis Object Cache c'est typiquement le genre d'optimisation que les agences vendent 800 euros et que vous pouvez faire vous-meme un mardi soir entre deux series. La courbe d'apprentissage est plate, les benefices visibles immediatement dans GTmetrix, et vos visiteurs s'en rendent compte sans savoir pourquoi.

Derniere chose : surveillez votre hit ratio dans le temps. Un cache qui tombe a 70% c'est le signe qu'un truc a change. Plugin recemment installe qui flush trop, mise a jour WordPress qui change la structure des transients, theme qui appelle des options exotiques. Garder un oeil dessus une fois par mois suffit pour rester en zone verte.

# Articles similaires

Sur les memes sujets et plus loin