Cache objet Redis sur WordPress : quand et comment

Ce que tu vas apprendre

Redis revient dans toutes les conversations dès qu’un site WordPress rame, souvent confondu avec le cache de pages. Ce n’est pas la même chose, et l’activer sur le mauvais projet ne change littéralement rien à la vitesse ressentie. Cet article explique ce que fait vraiment le cache objet, comment l’activer proprement (hébergeur + plugin), et surtout dans quels cas il n’apporte aucun bénéfice.

Prérequis :

• Accès SSH ou terminal chez ton hébergeur (ou support technique joignable)
• Droits administrateur sur WordPress et accès FTP/SFTP à wp-config.php
• Un site avec un trafic réel ou du WooCommerce actif (le cache objet cible ce cas)
• Idéalement, Query Monitor déjà installé pour mesurer avant/après

Comprendre ce que fait vraiment le cache objet

WordPress interroge sa base de données MySQL en permanence : à chaque affichage de page, il récupère les options, les métadonnées de posts, les menus, les traductions, les résultats de requêtes complexes. Ces données sont souvent identiques d’une requête à l’autre — mais sans cache objet, WordPress les redemande systématiquement à la base.

Le cache objet (Redis ou Memcached) stocke ces résultats en mémoire vive, sur un serveur séparé de MySQL. Au lieu de repasser par une requête SQL, WordPress lit directement dans la RAM. Le gain est invisible à l’œil nu sur une page simple, mais devient concret dès que :

• WooCommerce est actif : chaque page produit, chaque calcul de panier, chaque vérification de stock déclenche des dizaines de requêtes transients et de meta queries.
• Le site a beaucoup de trafic simultané : sans cache objet, chaque visiteur en même temps tape sur la même base, qui finit par saturer.
• Tu utilises des plugins lourds en requêtes (constructeurs de pages, multilingue, ACF avec des champs répétés) — voir notre comparatif des meilleurs plugins de cache WordPress pour la différence entre cache de page et cache objet.

À l’inverse, sur un site vitrine avec peu de trafic et un bon cache de page (via LiteSpeed Cache par exemple), le cache objet ne fera quasiment aucune différence : les visiteurs anonymes reçoivent déjà des pages entièrement en cache, sans jamais toucher la base.

Vérifier que ton hébergeur propose Redis

C’est le point qui bloque la moitié des tentatives. Redis doit tourner comme service serveur, pas comme simple extension PHP. Impossible de l’installer soi-même sur un mutualisé classique sans accès root.

• Sur un VPS ou serveur dédié, installe Redis via le gestionnaire de paquets (apt install redis-server sur Debian/Ubuntu), puis vérifie qu’il tourne : redis-cli ping doit répondre PONG.
• Sur un hébergement managé WordPress (Kinsta, WP Engine, certains plans o2switch ou OVH avancés), Redis est souvent proposé en activation depuis le panneau, sans terminal.
• Sur un mutualisé basique, c’est rarement disponible. Vérifie l’espace client ou contacte le support avant de perdre du temps sur le plugin.

Si tu dois te connecter en SSH pour vérifier ou configurer le service, notre guide se connecter en SSH sur OVH détaille la marche à suivre pour un VPS classique.

Installer et activer Redis Object Cache

Une fois Redis actif côté serveur, la partie WordPress est rapide :

1. Installe le plugin Redis Object Cache (par Till Krüss) depuis le répertoire officiel WordPress.
2. Dans wp-config.php, ajoute les constantes de connexion, juste avant la ligne /* That's all, stop editing! */ :

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_TIMEOUT', 1);
define('WP_CACHE', true);

3. Va dans Réglages > Redis et clique sur Enable Object Cache.
4. Le plugin affiche un statut “Connected” avec le temps de réponse Redis (généralement moins de 1 ms en local). Si tu vois une erreur de connexion, vérifie le port, le firewall interne, ou demande à l’hébergeur si un socket Unix est requis à la place du TCP.

Sur les hébergements managés qui gèrent Redis nativement, le plugin détecte souvent la configuration automatiquement — pas besoin de toucher à wp-config.php.

Configurer et vérifier que le cache fonctionne réellement

Une activation “réussie” dans l’interface ne garantit pas un vrai gain. Vérifie concrètement :

• Dans Réglages > Redis, regarde le nombre de hits vs misses. Un ratio de hits élevé (au-dessus de 90 % après quelques minutes de navigation) confirme que le cache travaille.
• Active le débogage transitoire avec Query Monitor : le nombre de requêtes SQL par page doit chuter nettement, surtout sur les pages WooCommerce.
• Purge le cache Redis après chaque changement de contenu structurant (thème, plugin critique) via le bouton Flush Cache du plugin, pour éviter de servir des données obsolètes.

Si le site reste lent malgré Redis actif, le problème est probablement ailleurs : PHP sous-dimensionné, requêtes non indexées en base, ou un plugin qui multiplie les appels — notre guide sur le diagnostic complet d’un site lent couvre ces autres causes.

Quand Redis n’apporte rien

Le cache objet n’est pas une optimisation universelle. Il ne sert à rien, voire complique la maintenance, dans ces cas :

• Site vitrine à faible trafic sans e-commerce : le cache de page couvre déjà 95 % des visites.
• Hébergement mutualisé sans accès à Redis : impossible à activer proprement, et les extensions de simulation (fichiers) n’apportent pas le même gain.
• Site déjà lent à cause du PHP ou d’un thème mal codé : Redis accélère les requêtes base, pas l’exécution PHP. Vérifie d’abord les directives PHP et la mémoire allouée.
• Petit catalogue WooCommerce (moins de 50 produits, faible trafic) : le gain est marginal comparé à la complexité de maintenance ajoutée.

Tableau récapitulatif

Pièges courants

• Activer Redis sans vérifier les hits : une installation qui affiche “Connected” mais avec 0 hit ne sert à rien — vérifie toujours le ratio.
• Oublier de flusher après une migration ou un changement de thème : le site peut afficher du contenu périmé.
• Confondre cache objet et cache de page : ce sont deux couches différentes, souvent utiles ensemble mais pas interchangeables.
• Mutualiser Redis entre plusieurs sites sans préfixe : sans WP_CACHE_KEY_SALT unique par site, les données peuvent se mélanger entre installations WordPress sur le même serveur.
• Négliger les erreurs WooCommerce qui persistent malgré Redis : si le panier ou le checkout bloque toujours, le problème vient d’ailleurs — voir notre guide des erreurs WooCommerce courantes.

Sur un site WooCommerce actif ou à trafic soutenu, Redis correctement configuré et vérifié via son ratio de hits change réellement la donne. Sur un site vitrine classique, l’énergie est mieux investie dans un bon cache de page et des directives PHP correctement réglées.