Redis et WordPress : Configuration du Cache Objet pour des Performances Maximales

WordPress dispose d’un système de cache interne appelé l’Object Cache. Par défaut, ce cache est en mémoire PHP (non-persistant) : il est vidé à chaque requête HTTP et ne survit pas entre deux chargements de page. Résultat : WordPress exécute les mêmes requêtes SQL des dizaines de fois par minute sur des sites à fort trafic. Le cache objet persistent résout ce problème en stockant les résultats de requêtes en dehors de PHP, dans un système tiers. Redis est aujourd’hui le standard pour ce rôle. La différence est radicale : un site WordPress avec 500 visiteurs simultanés passe de 4 000 requêtes MySQL/minute à 800 avec Redis activé. Le Time To First Byte (TTFB) peut chuter de 300ms à 50ms. Pour comprendre la différence avec le cache de pages (WP Super Cache, W3 Total Cache) : le cache de pages stocke le HTML généré pour les visiteurs non connectés. Le cache objet, lui, accélère la génération du HTML pour tous les utilisateurs, y compris les utilisateurs connectés, les administrateurs et les pages personnalisées par cart WooCommerce.

Redis vs Memcached

Memcached est l’alternative historique à Redis. Voici pourquoi Redis s’est imposé :

Verdict pour WordPress : choisissez Redis. La persistance est décisive : si votre serveur redémarre (mise à jour, incident), le cache Redis est rechargé depuis le disque en quelques secondes. Avec Memcached, tout est perdu et WordPress doit reconstruire l’intégralité du cache depuis MySQL, créant un pic de charge dangereux (“thundering herd”). De plus, l’écosystème Redis est beaucoup plus actif et le plugin WordPress officiel est maintenu en priorité pour Redis.

Installer Redis sur le Serveur

Sur Ubuntu/Debian :

# Mettre à jour les paquets
sudo apt update

# Installer Redis
sudo apt install redis-server -y

# Vérifier que Redis fonctionne
redis-cli ping
# Réponse attendue : PONG

# Démarrer Redis automatiquement au boot
sudo systemctl enable redis-server
sudo systemctl start redis-server

# Vérifier le statut
sudo systemctl status redis-server

Configuration de base dans /etc/redis/redis.conf :

# Limiter la mémoire utilisée par Redis (adapter selon votre RAM disponible)
maxmemory 256mb

# Politique d'éviction quand la mémoire est pleine
# allkeys-lru : supprime les clés les moins récemment utilisées
maxmemory-policy allkeys-lru

# Activer la persistance RDB (snapshot toutes les 15 minutes si 1+ modification)
save 900 1
save 300 10
save 60 10000

# Socket Unix pour de meilleures performances (optionnel)
unixsocket /var/run/redis/redis.sock
unixsocketperm 770

Après modification de la configuration, redémarrez Redis : sudo systemctl restart redis-server

Sur CentOS/RHEL : sudo yum install redis puis sudo systemctl enable --now redis

Extension PHP Redis

Redis nécessite une extension PHP pour que WordPress puisse communiquer avec lui. Deux options :

Option 1 — Extension native php-redis (recommandée) :

# Ubuntu/Debian
sudo apt install php-redis

# Ou si vous utilisez PHP 8.2 spécifiquement
sudo apt install php8.2-redis

# Vérifier l'installation
php -m | grep redis
# Doit afficher : redis

# Redémarrer PHP-FPM
sudo systemctl restart php8.2-fpm

Option 2 — Predis via Composer (si vous ne pouvez pas installer d’extensions PHP) :

composer require predis/predis

Predis est une implémentation PHP pure, plus lente que l’extension native mais fonctionnelle sans accès root. Le plugin Redis Object Cache la supporte nativement.

Vérifier dans php.ini que l’extension est bien chargée :

php -i | grep redis

Plugin Redis Object Cache pour WordPress

Le plugin officiel Redis Object Cache de Till Krüss est la solution standard. Plus de 200 000 installations actives et maintenu activement.

Installation : depuis le tableau de bord WordPress → Extensions → Ajouter → chercher “Redis Object Cache” → Installer → Activer.

Configuration dans wp-config.php :

// Connexion Redis (avant la ligne "That's all, stop editing!")
define('WP_REDIS_HOST', '127.0.0.1');        // ou 'localhost'
define('WP_REDIS_PORT', 6379);               // port par défaut Redis
define('WP_REDIS_DATABASE', 0);              // base de données (0-15)
define('WP_REDIS_TIMEOUT', 1);               // timeout connexion en secondes
define('WP_REDIS_READ_TIMEOUT', 1);          // timeout lecture
define('WP_REDIS_PREFIX', 'monsite_');       // préfixe pour isoler les clés

// Si vous utilisez le socket Unix (plus performant)
define('WP_REDIS_PATH', '/var/run/redis/redis.sock');

// Si Redis nécessite un mot de passe
define('WP_REDIS_PASSWORD', 'votre_mot_de_passe');

// Pour un réseau Multisite (isole chaque site)
define('WP_REDIS_SELECTIVE_FLUSH', true);

Activation du drop-in : dans le tableau de bord WordPress → Extensions → Redis Object Cache → cliquez “Activer le cache objet”. Cela copie le fichier object-cache.php dans wp-content/. Ce fichier est le point d’entrée : WordPress le charge avant tout plugin et l’utilise pour toutes les opérations de cache.

Mesurer les Performances

Avant d’activer Redis, prenez des mesures de référence avec Query Monitor (plugin WordPress gratuit) :

• Nombre de requêtes SQL par page
• Temps total d’exécution PHP
• TTFB mesuré avec Chrome DevTools ou GTmetrix

Après activation de Redis, comparez. Voici des exemples de gains réels observés :

Dans Redis, chaque clé mise en cache correspond à une requête SQL évitée. Pour visualiser le cache en temps réel :

redis-cli monitor
# Affiche en temps réel toutes les opérations Redis (mode debug)

redis-cli info stats
# Statistiques globales : keyspace_hits, keyspace_misses, hit rate

Redis sur les Hébergements Mutualisés

Redis nécessite un accès serveur que tous les hébergeurs ne proposent pas :

OVH Hébergement Mutualisé : Redis n’est pas disponible sur les offres mutualisées OVH. Alternative : utilisez l’API Transients de WordPress (set_transient() / get_transient()) qui stocke dans la base de données. Moins performant qu’un vrai cache objet, mais meilleur que rien. Pour Redis, il faut passer sur un VPS OVH (à partir de 3,50 €/mois).

Kinsta : Redis est inclus nativement dans tous les plans Kinsta (hébergeur WordPress premium). Activable en un clic depuis le tableau de bord MyKinsta. C’est l’une des raisons pour lesquelles Kinsta est recommandé pour les sites WooCommerce à fort trafic.

WP Engine : Redis est disponible comme add-on payant sur WP Engine. Il est activable depuis le portail utilisateur et configuré automatiquement.

Cloudways : Redis Object Cache est inclus et pré-configuré sur toutes les instances Cloudways. Activable depuis l’interface en un clic.

Contournement sur mutualisé : si Redis est impossible, utilisez les Transients WordPress de manière stratégique pour mettre en cache les requêtes WP_Query coûteuses :

$cache_key = 'articles_vedette_' . md5(serialize($args));
$result = get_transient($cache_key);
if (false === $result) {
    $result = new WP_Query($args);
    set_transient($cache_key, $result, HOUR_IN_SECONDS);
}

Besoin d’un expert ? Audit Performance Paris →

Questions Fréquentes

Redis est-il disponible sur tous les hébergements WordPress ?

Non. Redis nécessite un processus système persistant sur le serveur, ce qui est incompatible avec les hébergements mutualisés traditionnels (OVH, Ionos, PlanetHoster sur leurs offres d’entrée de gamme). En revanche, Redis est standard sur les hébergeurs WordPress premium (Kinsta, WP Engine, Cloudways, Flywheel) et disponible sur tout VPS où vous avez accès root. Si les performances sont critiques pour votre projet, c’est un critère de sélection d’hébergeur à part entière. Le passage d’un mutualisé avec cache de pages à un VPS avec Redis peut diviser le temps de réponse par 3 à 5.

Que se passe-t-il si Redis plante ? WordPress tombe-t-il aussi ?

Non, grâce au mécanisme de fallback. Le plugin Redis Object Cache détecte la perte de connexion Redis et bascule automatiquement sur le cache PHP en mémoire (non-persistant). WordPress continue de fonctionner normalement, simplement avec des performances réduites (retour aux requêtes MySQL complètes). Vous serez notifié via le tableau de bord WordPress. Ce comportement est configurable : la constante WP_REDIS_GRACEFUL_RECONNECTS contrôle les tentatives de reconnexion. Redis est donc un accélérateur, pas un composant critique dont dépend la disponibilité du site.

Redis remplace-t-il WP Super Cache ou W3 Total Cache ?

Non, ils sont complémentaires. Redis est un cache objet (accélère les requêtes PHP/MySQL pour tous les utilisateurs). WP Super Cache et W3 Total Cache sont des caches de pages (stockent le HTML généré pour les visiteurs non connectés). Un site WordPress parfaitement optimisé utilise les deux : Redis pour accélérer la génération des pages, et un cache de pages pour éviter de les générer du tout pour les visiteurs anonymes. Sur des sites WooCommerce, les pages panier et checkout ne peuvent pas être mises en cache de pages (contenu personnalisé), mais Redis accélère leur génération. W3 Total Cache peut d’ailleurs utiliser Redis comme backend pour son propre cache de pages et de base de données.

Quelle est la différence entre WP_REDIS_DATABASE et WP_REDIS_PREFIX ?

WP_REDIS_DATABASE sélectionne une base de données Redis parmi les 16 disponibles (numérotées 0 à 15). Redis permet d’isoler complètement différentes applications sur le même serveur : la base 0 pour WordPress, la base 1 pour une application Laravel, etc. WP_REDIS_PREFIX, en revanche, ajoute un préfixe à toutes les clés dans une même base de données. Il est utile en Multisite WordPress pour isoler les clés de chaque sous-site dans la même base Redis, ou pour éviter les collisions entre une instance de staging et de production sur le même serveur Redis. En pratique, pour un site seul, WP_REDIS_DATABASE = 0 et un WP_REDIS_PREFIX unique suffisent.