Parmi les conseils d’optimisation de WordPress, « installer Redis » est devenu presque un réflexe. Les plugins de performance le suggèrent, les hébergeurs le proposent en option, même l’outil Santé du site de WordPress le recommande. Pourtant, sur de nombreux sites, activer Redis ne produit aucune amélioration visible, alors que sur d’autres il change radicalement la vitesse des pages les plus importantes. La différence ne dépend pas de Redis, mais du problème que l’on cherche à résoudre.
Dans cet article, nous voyons ce qu’est le cache d’objets de WordPress, en quoi il diffère du cache de page, quand un cache persistant comme Redis fait vraiment la différence, quand il est inutile, et comment le configurer et le mesurer correctement.
Cache de page et cache d’objets : deux choses différentes
Le cache de page, que nous avons abordé dans l’article sur le TTFB et le cache de page, mémorise le HTML complet d’une page et le renvoie aux requêtes suivantes sans exécuter WordPress. C’est l’outil le plus efficace pour la performance : une page servie depuis le cache arrive en quelques dizaines de millisecondes, quelle que soit la complexité du site.
Le cache d’objets agit à un autre niveau. Il ne mémorise pas des pages, mais les données individuelles que WordPress utilise pour les construire : options du site, articles, métadonnées, taxonomies, résultats de certaines requêtes, transients des plugins. Quand WordPress doit générer une page, au lieu de demander ces données à la base de données à chaque fois, il regarde d’abord dans le cache. Il n’évite pas l’exécution de WordPress, mais il la rend plus rapide.
Le cache d’objets de WordPress, avec et sans Redis
WordPress a toujours eu un cache d’objets intégré : toutes les fonctions du cœur utilisent wp_cache_get() et wp_cache_set() pour mémoriser des données déjà lues. Par défaut, cependant, ce cache ne vit que dans la mémoire de la requête : il évite de lire deux fois la même option pendant la génération d’une page, mais à la requête suivante il repart de zéro. Chaque page générée doit tout relire dans la base de données.
Un cache persistant change ce comportement. Avec un fichier nommé object-cache.php dans le dossier wp-content, appelé drop-in, WordPress remplace sa propre implémentation par une qui enregistre les données dans un système externe, comme Redis ou Memcached, où elles restent disponibles d’une requête à l’autre. Le drop-in est généralement installé par un plugin, comme Redis Object Cache ou des solutions commerciales plus avancées, ou directement par l’hébergeur. Redis est un magasin de données en mémoire, extrêmement rapide : lire une valeur prend une fraction de milliseconde, contre les millisecondes d’une requête de base de données.
Avec un cache persistant actif, les transients changent eux aussi, ces données temporaires que de nombreux plugins utilisent pour mémoriser des résultats coûteux : au lieu d’être enregistrés dans la table des options de la base de données, ils sont enregistrés dans le cache. Et depuis la version 6.1, WordPress met aussi en cache les résultats de nombreuses requêtes de contenu, un avantage supplémentaire quand le cache est persistant.
Quand il est vraiment nécessaire
La question clé est la suivante : combien de pages du site sont générées par WordPress au lieu d’être servies depuis le cache de page ? Si la réponse est « presque aucune », Redis a peu à offrir. Si la réponse est « beaucoup », il peut faire une grande différence. Les cas typiques où le cache de page ne peut pas intervenir sont :
- Les boutiques en ligne. Panier, paiement, compte client et, dans de nombreuses configurations, chaque page visitée par quelqu’un qui a un produit dans son panier, comme l’explique l’article sur les Core Web Vitals pour WooCommerce.
- Les sites avec utilisateurs connectés. Espaces membres, sites d’abonnement, plateformes d’e-learning, forums et communautés, où les pages sont personnalisées.
- Les requêtes dynamiques. Recherche interne, filtres, API REST et appels AJAX, rarement mis en cache.
- L’administration. Le tableau de bord et l’éditeur, où les rédacteurs et les responsables travaillent tous les jours.
- Le cache froid. La première requête après une purge du cache de page, ou les pages rarement visitées qui ne sont jamais en cache.
Dans tous ces cas, chaque requête exécute l’intégralité de WordPress, et le nombre de requêtes de base de données peut se compter en dizaines ou en centaines. Les réduire avec un cache en mémoire abaisse le temps de génération, donc le TTFB, souvent de moitié ou plus, et allège en même temps la charge de la base de données, qui est fréquemment le goulet d’étranglement des sites à fort trafic dynamique.
Quand il n’est pas nécessaire
Pour un site vitrine ou un blog de quelques pages, visité presque uniquement par des utilisateurs anonymes et servi entièrement depuis le cache de page, Redis n’apporte aucun bénéfice mesurable aux visiteurs : leurs pages ne passent pas par WordPress. Il peut rendre le tableau de bord un peu plus rapide pour ceux qui écrivent, mais ce n’est pas une intervention sur les Core Web Vitals. Dans ces cas, la priorité est de s’assurer que le cache de page fonctionne bien et couvre chaque page.
Il existe aussi des cas où un cache persistant peut aggraver les choses. Si Redis se trouve sur un autre serveur avec une latence réseau importante, des centaines de lectures par page peuvent coûter plus que les requêtes qu’elles remplacent. Si la mémoire allouée est insuffisante, les données sont évincées en permanence et le taux de succès s’effondre. Et certains plugins mettent en cache des valeurs énormes, comme des listes entières de produits ou des réponses d’API externes, ce qui ralentit chaque lecture et sature la mémoire.
Configuration : les détails qui comptent
Une configuration correcte fait la différence entre un Redis qui accélère le site et un Redis qui ne fait qu’occuper de la mémoire. Quelques points méritent attention.
- Mémoire et politique d’éviction. Il faut fixer une limite de mémoire adaptée avec
maxmemory, ainsi qu’une politique d’éviction commeallkeys-lru, qui supprime les données les moins récemment utilisées quand la mémoire est pleine. Sans limite, Redis peut grossir jusqu’à mettre le serveur en difficulté. - Connexion locale. Si Redis se trouve sur le même serveur que PHP, un socket Unix réduit encore la latence par rapport à une connexion TCP.
- Persistance sur disque. Pour un cache, il n’est pas nécessaire d’enregistrer les données sur disque : si Redis redémarre, le cache se repeuple tout seul. Désactiver la persistance évite des écritures inutiles.
- Séparation entre les sites. Si plusieurs sites partagent la même instance, chacun doit avoir un préfixe de clés différent, pour éviter que les données se mélangent.
- Sérialisation et compression. Les solutions les plus avancées permettent des sérialiseurs plus efficaces et la compression des valeurs, utiles quand les données stockées sont nombreuses ou volumineuses.
# redis.conf : réglages typiques pour un cache WordPress
maxmemory 256mb
maxmemory-policy allkeys-lru
save ""
appendonly no
unixsocket /var/run/redis/redis.sock
unixsocketperm 770// wp-config.php : connexion par socket et préfixe dédié
define( 'WP_REDIS_SCHEME', 'unix' );
define( 'WP_REDIS_PATH', '/var/run/redis/redis.sock' );
define( 'WP_REDIS_PREFIX', 'negozio_' );
define( 'WP_REDIS_MAXTTL', 86400 );Les noms exacts des constantes dépendent du plugin utilisé ; ceux de l’exemple sont typiques du plugin Redis Object Cache. Sur de nombreuses plateformes d’hébergement géré, Redis est déjà configuré, et il suffit de l’activer depuis le panneau de contrôle.
Le problème des options chargées automatiquement
Un cas particulier mérite d’être signalé. À chaque requête, WordPress charge d’un seul coup toutes les options marquées comme chargées automatiquement (autoload), et avec un cache persistant il les mémorise comme une valeur unique. De nombreux plugins, même après avoir été désinstallés, laissent de grosses options dans cette liste. Le résultat est une valeur de plusieurs mégaoctets lue et désérialisée à chaque page générée, avec ou sans Redis. Vérifier la taille des options chargées automatiquement et nettoyer les inutiles est une intervention complémentaire qui vaut souvent autant que l’installation du cache lui-même ; l’outil Santé du site signale quand cette taille est excessive.
Redis ou Memcached ?
Memcached est l’autre solution éprouvée pour le cache d’objets de WordPress, et pour un usage typique comme cache, les performances des deux systèmes sont comparables. Redis s’est imposé comme choix par défaut grâce à quelques fonctions pratiques : il prend en charge des structures de données plus riches, permet de vider sélectivement des groupes de clés, offre des outils de diagnostic plus complets et est pris en charge par un écosystème de plugins plus large. Si votre hébergement propose déjà un Memcached bien configuré, il n’y a pas de raison de changer ; si vous partez de zéro, Redis est généralement le choix le plus simple à gérer.
Invalidation et vidage
Un cache n’est utile que si les données qu’il contient sont correctes. Le cœur de WordPress invalide automatiquement les entrées d’un article, d’un terme ou d’une option quand ils sont modifiés, et les plugins bien écrits font de même avec leurs propres données. Les problèmes surviennent avec le code qui écrit directement dans la base de données en contournant les fonctions de WordPress, par exemple lors d’imports en masse ou de scripts personnalisés : le cache continue de renvoyer les anciennes valeurs jusqu’à leur expiration ou jusqu’à son vidage.
Pour cette raison, il vaut la peine d’inclure un vidage du cache d’objets dans les procédures de mise en production et après toute opération directe sur la base de données, et de se méfier des solutions qui le vident trop souvent. Un plugin qui effectue un vidage complet à chaque enregistrement de contenu annule une grande partie du bénéfice : le taux de succès s’effondre précisément aux moments de pic d’activité.
Un exemple typique
Prenons une boutique d’environ trois mille produits, avec un cache de page efficace pour les visiteurs anonymes et un trafic concentré aux heures du soir. Les pages du catalogue répondent en 50 millisecondes ; le panier et le paiement, en revanche, prennent plus de 800 millisecondes, avec plus de 200 requêtes par page, et pendant les promotions la base de données atteint sa limite. Avec un Redis local, 256 mégaoctets de mémoire et un nettoyage des options chargées automatiquement, les requêtes par page tombent sous 40, le TTFB du panier et du paiement est divisé par deux et la charge de la base de données aux heures de pointe chute spectaculairement. Le catalogue reste à 50 millisecondes, comme avant : le cache de page faisait déjà le travail.
Comment mesurer l’effet
Avant d’activer Redis, il vaut la peine de mesurer le point de départ sur les pages qui ne passent pas par le cache de page : TTFB du panier, de l’espace membres, de la recherche, du tableau de bord. Le plugin Query Monitor montre, pour chaque page, le nombre de requêtes de base de données, leur temps total et, avec un cache persistant actif, le pourcentage de lectures servies par le cache. Côté Redis, la commande INFO stats indique le total des succès et des échecs, dont on peut déduire le ratio global.
Après l’activation, les signes d’une configuration efficace sont clairs : les requêtes par page diminuent nettement, le taux de succès reste au-dessus de 90 %, le TTFB des pages dynamiques se réduit. Si les requêtes ne diminuent pas, le drop-in n’est peut-être pas actif ; si le taux de succès est bas, la mémoire est probablement insuffisante ou un plugin vide le cache trop souvent.
En bref
Un cache d’objets persistant avec Redis ne remplace pas le cache de page et n’accélère pas les pages que le cache de page sert déjà. Son domaine, c’est tout ce que WordPress doit générer à chaque requête : paniers et paiements, espaces membres, utilisateurs connectés, recherches, API et administration. Là, il peut diviser par deux le temps de réponse et alléger la base de données, avec des effets directs sur le TTFB et donc sur le LCP des pages les plus importantes pour l’activité.
Pour un site vitrine entièrement en cache, il sert peu ; pour une boutique en ligne ou un site avec beaucoup d’utilisateurs connectés, c’est souvent l’une des mesures les plus efficaces. Ce qui fait la différence, c’est la configuration, avec une mémoire adaptée, une connexion locale et des préfixes séparés, et la mesure, avant et après, sur les bonnes pages.
