Cache d’objets Redis pour WordPress : le guide complet

À chaque visite, WordPress interroge sa base de données, range les résultats dans un cache en mémoire, puis oublie tout à la fin de la requête. La visite suivante recommence le même travail. C’est le comportement par défaut, et c’est la raison pour laquelle la Santé du site recommande, sur de nombreux sites, un cache d’objets persistant.

Redis est devenu la réponse la plus courante à cette recommandation. Bien configuré, il évite à WordPress des milliers de requêtes répétées sur une boutique, un site de membres ou un forum. Mal configuré, il remplit la mémoire du serveur, sert des données périmées, ou fait tomber plusieurs sites d’un coup.

Ce guide explique ce qu’est le cache d’objets de WordPress, ce que change sa version persistante, comment lire la recommandation de la Santé du site, comment choisir entre Redis, Memcached et les autres solutions, quels plugins utiliser, comment configurer l’ensemble, et quand tout cela ne sert à rien.

Ce qu’est le cache d’objets de WordPress

Les fonctions wp_cache et les groupes

WordPress dispose depuis la version 2.0 d’une interface de cache d’objets : des fonctions comme wp_cache_get(), wp_cache_set() ou wp_cache_delete() rangent des données sous une clé, dans un groupe. Le cœur s’en sert pour les options, les articles, les termes, les utilisateurs, et depuis WordPress 6.1 pour les résultats des requêtes de contenus.

Un plugin peut l’utiliser de la même façon. La documentation recommande de passer par ces fonctions, jamais directement par la classe qui les porte :

$found = false;
$data  = wp_cache_get( 'top_products', 'my-plugin', false, $found );
if ( ! $found ) {
	$data = my_plugin_expensive_query();
	wp_cache_set( 'top_products', $data, 'my-plugin', HOUR_IN_SECONDS );
}

Le paramètre $found permet de distinguer une valeur false mise en cache d’une absence de valeur.

Pourquoi le cache par défaut disparaît avec la requête

Sans configuration particulière, ce cache n’est pas persistant : les données vivent en mémoire, dans un simple tableau PHP, le temps d’une requête. La durée d’expiration passée à wp_cache_set() n’y est même pas utilisée. Le cache évite donc de répéter une requête au cours d’un même affichage, mais la page suivante repart de zéro.

Ce que WordPress met déjà en cache

Les options chargées automatiquement sont regroupées sous une seule clé, lue à chaque requête. Les articles, les termes et leurs métadonnées passent aussi par le cache. Depuis WordPress 6.1, les résultats des requêtes de contenus sont mis en cache à leur tour, une amélioration annoncée à l’époque comme majeure pour la base de données, surtout avec un cache persistant.

Les options chargées automatiquement

Ces options, regroupées sous une seule clé, sont lues à chaque requête : avec un cache persistant, tout ce bloc transite donc chaque fois par le serveur de cache, d’où l’intérêt de le garder léger. Depuis WordPress 6.6, une option de plus de 150 000 octets n’est plus chargée automatiquement par défaut. Sur Memcached, la limite d’un mégaoctet par élément s’applique à ce bloc d’options, ce qui explique les erreurs de certains sites très chargés en réglages de plugins.

Ce que change un cache d’objets persistant

Le fichier object-cache.php

Un cache persistant ne s’active pas par un réglage. Il repose sur un fichier, wp-content/object-cache.php, qu’un plugin installe. Si ce fichier existe, WordPress le charge automatiquement au démarrage et lui confie toutes les opérations de cache, qui vont alors vers un serveur de cache comme Redis ou Memcached. L’écran des plugins le signale comme un cache d’objets externe.

Ne le confondez pas avec advanced-cache.php, qui sert le cache de pages et ne se charge que si la constante WP_CACHE est active. Ce sont deux fichiers, deux caches différents.

Les transients quittent la base

Avec un cache persistant, les transients, ces données temporaires que les plugins stockent avec une date d’expiration, ne sont plus enregistrés dans la table des options mais dans le cache. La documentation prévient aussi qu’un transient ne doit jamais être supposé présent en base, et qu’il peut disparaître avant son expiration.

Cache d’objets et cache de pages

Le cache de pages enregistre la page HTML complète et la sert sans exécuter WordPress. Le cache d’objets intervient quand WordPress s’exécute réellement : visiteur connecté, administration, panier, commande, compte client, recherche, appels à l’API. Un visiteur anonyme servi par le cache de pages ne touche jamais au cache d’objets. Notre sélection des plugins de vitesse WordPress détaille la partie cache de pages.

La recommandation de la Santé du site, décodée

Depuis WordPress 6.1, la Santé du site peut recommander un cache d’objets persistant. Ce n’est pas une alerte critique mais une recommandation, et elle n’apparaît que sur un environnement de production, le type que WordPress retient par défaut quand aucun autre n’est déclaré.

Le test ne mesure aucune performance : il compare le volume de données à des seuils. Il se déclenche toujours sur un multisite, et sinon dès que le site compte plus de 500 options chargées automatiquement, plus de 100 000 octets de ces options, ou au moins 1 000 lignes dans les tables des commentaires, options, articles, termes ou utilisateurs. Un filtre permet aux hébergeurs et aux développeurs d’ajuster ces seuils.

Le texte de la recommandation renvoie vers votre hébergeur pour savoir si un cache persistant peut être activé, et liste les extensions PHP de cache que WordPress détecte sur le serveur. La documentation officielle résume le bénéfice ainsi : moins d’allers-retours vers la base de données, donc des pages générées plus vite.

Redis, Memcached et les autres

Redis

Redis est un serveur de données en mémoire. Pour WordPress, il apporte des bases numérotées, seize par défaut, qui permettent d’isoler chaque site, et un langage de scripts qui permet aux plugins de vider un seul groupe de cache. Sa licence a fait débat : passée sous des licences restrictives en mars 2024, elle a donné naissance au fork libre Valkey, puis Redis 8 a ajouté en mai 2025 une licence open source AGPL.

Par défaut, Redis n’est pas configuré comme un cache : sans limite de mémoire sur un système 64 bits, et avec une politique qui refuse d’écrire plutôt que d’effacer quand la mémoire est pleine. Il faut le régler, nous y reviendrons.

Memcached

Memcached est plus simple : un cache en mémoire, multithread, sans réplication ni bases numérotées, avec une limite historique d’un mégaoctet par élément. Il reste bien vivant chez les grands hébergeurs : WordPress VIP fournit à chaque environnement son propre cluster Memcached. Sans bases numérotées, vider le cache d’un site risque de vider celui de tous les sites du serveur, ce que les bons fichiers de cache contournent.

Sans serveur de cache

Sur un hébergement mutualisé sans Redis ni Memcached, des solutions existent. APCu garde les données dans la mémoire de PHP, mais seulement sur un serveur, et la ligne de commande, où il est désactivé par défaut, ne partage pas cette mémoire. SQLite Object Cache s’appuie sur un fichier SQLite et ne fonctionne pas correctement avec plusieurs serveurs web. Docket Cache stocke le cache sous forme de fichiers PHP, en reconnaissant lui-même que Redis ou Memcached restent les meilleurs choix.

Comment choisir

Si votre hébergeur propose Redis, choisissez Redis : c’est l’option la mieux prise en charge par les plugins WordPress, et ses bases séparées simplifient l’isolement de plusieurs sites. Si votre hébergeur fournit et gère Memcached, utilisez le fichier de cache qu’il recommande. Sans serveur de cache, APCu ou SQLite dépannent un site hébergé sur un seul serveur, à condition d’accepter leurs limites. Dans tous les cas, demandez à l’hébergeur qui surveille le service et ce qui se passe s’il s’arrête.

Relay

Relay, développé notamment par Till Krüss, l’auteur d’Object Cache Pro, est une extension PHP qui remplace le client Redis et garde une copie partielle des données dans la mémoire partagée de PHP. Sa version gratuite est limitée à 64 Mo. Les gains annoncés par l’éditeur restent ses propres chiffres.

Les plugins comparés

Redis Object Cache

Le plugin gratuit de référence, maintenu par Till Krüss, compte plus de 500 000 installations et en est à la version 3.0, sortie en septembre 2026. Il prend en charge plusieurs clients PHP, la réplication et les clusters, propose des commandes WP-CLI et affiche le taux de réussite du cache dans la barre d’administration. Kinsta l’installe avec son option Redis.

Object Cache Pro

Sa version commerciale, réécrite, coûte 95 dollars par mois ou 950 dollars par an au moment où nous écrivons, sans le serveur Redis. Elle ajoute la compression, le préchargement, des statistiques et des options fines de vidage. Elle cesse de fonctionner quatorze jours après l’expiration de la licence. Plusieurs hébergeurs, comme Pantheon ou Cloudways, l’incluent dans leurs offres.

LiteSpeed Cache et W3 Total Cache

LiteSpeed Cache, installé sur plus de sept millions de sites, contient un module de cache d’objets désactivé par défaut, qui se connecte à Memcached, à son équivalent LiteSpeed ou à Redis. W3 Total Cache propose aussi un module d’objets, avec une longue liste de méthodes dont certaines reposent sur des extensions PHP abandonnées. Ce sont des solutions pratiques si vous utilisez déjà ces plugins pour le cache de pages.

Les autres

WP Redis, le plugin historique de Pantheon, n’est plus la méthode recommandée par son propre éditeur. La fiche du plugin Memcached Object Cache sur le répertoire officiel n’a pas été mise à jour depuis 2022, même si son code reste maintenu ailleurs. Pour comparer ces offres avec celles des hébergeurs, notre sélection des hébergeurs WordPress compte la mise en cache parmi ses critères de choix.

Bien configurer l’ensemble

Côté Redis

La documentation de Redis recommande, pour un usage en cache, de fixer une limite de mémoire et une politique d’éviction. La politique allkeys-lru, qui efface les clés les moins récemment utilisées, est présentée comme un bon choix par défaut :

maxmemory 256mb
maxmemory-policy allkeys-lru

La valeur de mémoire dépend de votre site : c’est un exemple. Redis doit aussi n’écouter que localement ou sur un réseau privé, et exiger un mot de passe dès qu’il n’est pas strictement local.

Côté WordPress

Avec Redis Object Cache, les réglages se placent dans wp-config.php, avant la ligne qui demande d’arrêter les modifications. Chaque site doit avoir sa propre base Redis et un préfixe lisible :

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 3 );     // one database per site
define( 'WP_REDIS_PREFIX', 'shop:' ); // readable, unique per site

Activez ensuite le cache depuis l’écran du plugin ou avec wp redis enable, puis videz-le une fois. En cas de problème, supprimer le fichier object-cache.php ou définir WP_REDIS_DISABLED désactive tout immédiatement.

Le cas réel : quand les caches de requêtes s’empilaient dans Redis

L’histoire des caches de requêtes de WordPress, de 2022 à 2025, montre ce qui arrive quand un cache persistant n’a ni limite de mémoire ni politique d’éviction. Elle est entièrement documentée par les notes des développeurs du cœur, les commits publics et le journal des modifications d’Object Cache Pro.

Une promesse en 2022

En septembre 2022, à l’approche de WordPress 6.1, Jonny Harris, contributeur de l’équipe performance, annonce une amélioration massive des performances de la base de données : les résultats des requêtes de contenus seront désormais mis en cache. Avec un cache persistant, une même requête ne sera plus exécutée tant que le cache n’est pas invalidé.

Dans les commentaires de la note de développement, Till Krüss, auteur de Redis Object Cache, prévoit une charge un peu plus élevée sur Redis, négligeable selon lui comparée à l’attente de MySQL. WordPress 6.1 sort le 1er novembre 2022.

Une clé qui change à chaque modification

Le mécanisme d’invalidation est simple : la clé de chaque requête en cache contient la date de la dernière modification des contenus. Dès qu’un article est enregistré, cette date change, et toutes les requêtes déjà en cache deviennent inaccessibles, sans être effacées. Elles restent dans Redis jusqu’à expiration ou éviction.

Or WordPress n’impose pas d’expiration par défaut, et Redis, par défaut, n’a ni limite de mémoire ni politique d’éviction. Sur un site qui publie ou met à jour souvent, les entrées orphelines s’accumulent.

Isoler, puis réparer

Un premier correctif, intégré à WordPress 6.3 en août 2023, range ces résultats dans des groupes dédiés, nommés par exemple post-queries. Les développeurs peuvent alors leur appliquer une expiration ou les exclure du cache persistant. En mars 2025, Till Krüss propose sur GitHub d’unifier le format de ces clés, qu’il juge impossibles à analyser : deux horodatages y sont accolés sans règle commune.

En juin 2025, Object Cache Pro ajoute une durée de vie par défaut de 24 heures pour ces groupes, et une commande pour purger les anciennes requêtes. Le correctif de fond arrive dans le cœur le 31 août 2025 : la date n’est plus dans la clé mais dans la valeur, qui est mise à jour sur place. Le commit le dit sans détour : l’ancienne approche comptait sur le serveur de cache pour évincer les clés périmées, avec une efficacité variable.

WordPress 6.9 et après

WordPress 6.9, sorti le 2 décembre 2025, apporte de nouvelles fonctions de cache, dont wp_cache_get_salted(), sans que les fichiers de cache des plugins aient besoin d’être modifiés. La note de développement prévient d’une hausse temporaire des échecs de cache après la mise à jour, et suggère d’évincer les anciennes clés pour éviter qu’elles ne provoquent des évictions inutiles.

Ce qu’il faut en retenir

Un cache persistant n’est sain que si sa politique de mémoire l’est : fixez une limite et une politique d’éviction, car les réglages par défaut de Redis supposent une base de données, pas un cache. Invalider en changeant la clé coûte peu à l’application et cher au serveur de cache. Surveillez la mémoire utilisée et les clés évincées, pas seulement le taux de réussite. Les sources consultées ne publient pas la mémoire réellement consommée sur les sites concernés : retenez le mécanisme, pas un chiffre.

Les pièges

La mémoire et l’éviction

Quand une limite de mémoire est fixée sans changer la politique par défaut, un Redis plein refuse les nouvelles écritures, et le plugin affiche des erreurs de mémoire. Le plugin Redis Object Cache propose une durée de vie maximale, WP_REDIS_MAXTTL, pour en sortir, mais la vraie solution reste une limite de mémoire et une politique d’éviction côté serveur.

Un Redis partagé

Un préfixe évite les collisions de clés entre sites, pas les vidages : vider une base Redis efface tout ce qu’elle contient. Cloudways l’a constaté en 2023 : ses applications partageaient la même base Redis, et vider le cache d’une application vidait celui de toutes les autres sur le serveur. L’hébergeur a donné à chaque application sa propre base. La documentation d’Object Cache Pro déconseille fortement de partager une base entre plusieurs sites.

Le vidage

Videz le cache une fois après l’activation, et après une mise à jour qui change les clés de cache, comme le passage à WordPress 6.9. Sur un multisite, un vidage peut concerner tous les sites ou un seul selon le plugin et la commande. Vérifiez ce que fait votre outil avant de vider en production.

Quand Redis tombe

Le comportement dépend du plugin. Redis Object Cache arrête le site avec une erreur, par conception : pour Till Krüss, le cache d’objets doit être disponible en permanence, comme la base de données. En juin 2025, un administrateur a vu ainsi une quinzaine de sites tomber après une mise à jour serveur qui avait cassé Redis, quand ses sites sous LiteSpeed continuaient de tourner. Un repli silencieux sur la base expose en revanche à des données périmées au retour de Redis. Faites surveiller Redis comme votre base de données.

Après un déploiement ou une copie

Un déploiement de code ne vide pas le cache d’objets : WordPress VIP le précise dans sa documentation. Après la mise en ligne d’une modification qui change la structure des données mises en cache, videz-le explicitement. De même, une copie de site vers un environnement de test ou de production doit s’accompagner d’un vidage, et l’environnement de test ne doit jamais partager la base Redis de la production.

Les données périmées

Un plugin qui écrit directement en SQL, sans passer par les fonctions de WordPress, laisse le cache affiché inchangé. La documentation recommande, après une écriture directe, d’appeler clean_post_cache() pour l’article concerné. C’est souvent la cause d’un « bug » qui disparaît quand on vide le cache.

La sécurité

Redis est conçu pour être utilisé par des clients de confiance, dans un environnement de confiance. Une seule commande suffit à un attaquant pour effacer toutes les données d’un Redis exposé. En octobre 2025, la faille CVE-2025-49844, notée 10 sur 10, a imposé de mettre Redis à jour : elle est corrigée dans les versions 8.2.2, 8.0.4, 7.4.6 et 7.2.11, et ne peut être exploitée que par un client authentifié. Gardez Redis hors d’Internet, protégé par un mot de passe et à jour.

Mesurer le gain

Mesurez sur les pages que le cache de pages ne sert pas : administration, compte client, panier, recherche. Sur une même adresse, comparez avant et après avec Query Monitor, qui affiche le nombre de requêtes, leur durée et le taux de réussite du cache, et avec les statistiques de Redis. Les commandes de notre sélection de commandes WP-CLI essentielles, comme wp cache type, aident à vérifier le cache réellement utilisé.

Côté serveur, la commande redis-cli info stats donne le nombre de réussites et d’échecs du cache, dont on tire le taux de réussite, ainsi que le nombre de clés évincées et expirées. Un nombre de clés évincées qui grimpe sans cesse signale une mémoire trop juste ; un taux de réussite faible, un cache mal utilisé ou vidé trop souvent.

Mesurez aussi sous charge. Dans un guide mis à jour en décembre 2024, l’hébergeur Wetopi a mesuré sur une page d’exemple une chute du nombre de requêtes de 132 à 31, avec un taux de réussite de 99,3 %, mais un temps de génération à peine amélioré, de 0,29 à 0,27 seconde. Sa conclusion : dans ce cas, le cache d’objets n’aide vraiment que lorsque de nombreux utilisateurs sollicitent le site en même temps, en allégeant la base de données.

Quand un cache d’objets ne sert à rien

Kinsta l’écrit clairement : Redis n’aide généralement pas le temps de chargement des blogs statiques, des sites vitrines et des sites d’actualité, presque entièrement servis par le cache de pages. Il peut aider les boutiques, les sites de membres, les forums et les sites aux commentaires très actifs.

Un cache d’objets peut même ralentir un site si les plugins multiplient les appels : le plugin WP Redis prévient qu’une page qui déclenche 2 000 appels à Redis peut perdre deux secondes en transactions de cache. Si le site est plus lent avec le cache, quelque chose est cassé : connexion, latence ou ressources du serveur Redis. Une base de données mal entretenue reste aussi un problème que le cache ne fait que masquer.

Tableau récapitulatif

Solution	Ce qu’il faut	Idéale pour	Limite principale
Redis Object Cache	Un serveur Redis	La plupart des sites dynamiques	Site arrêté si Redis tombe
Object Cache Pro	Redis et une licence	Boutiques et sites à fort trafic	95 dollars par mois, sans Redis
LiteSpeed Cache	Memcached, LSMCD ou Redis	Sites déjà sous LiteSpeed	Module désactivé par défaut
Memcached	Un serveur Memcached	Grandes plateformes	Pas de bases séparées
APCu, SQLite, fichiers	Des extensions PHP ou le disque	Mutualisé, un seul serveur	Pas de partage entre serveurs

Questions fréquentes

Ai-je besoin de Redis si j’ai déjà un cache de pages ?

Pour un site vitrine ou un blog, rarement. Le cache de pages sert la majorité des visiteurs. Pour une boutique, un site de membres ou tout site avec beaucoup de visiteurs connectés, oui, car ces pages échappent au cache de pages.

Redis ou Memcached pour WordPress ?

Redis, dans la plupart des cas : ses bases séparées et ses scripts facilitent l’isolement des sites et le vidage ciblé, et les plugins WordPress les plus utilisés le ciblent. Memcached reste un bon choix quand l’hébergeur le fournit et le gère.

Object Cache Pro vaut-il 95 dollars par mois ?

Pour une boutique ou une plateforme à fort trafic, ses statistiques, sa compression et ses options de vidage peuvent se justifier. Pour la plupart des sites, le plugin gratuit suffit.

Le cache d’objets est-il sûr sur un hébergement mutualisé ?

Seulement si chaque compte dispose de sa propre instance Redis, protégée par un mot de passe : une base numérotée sépare les clés, pas les accès, et le mot de passe d’une instance est commun à tous ses clients. Les options chargées automatiquement, clés d’API comprises, sont copiées dans le cache.

Que se passe-t-il si Redis plante ?

Avec Redis Object Cache, le site s’arrête avec une erreur jusqu’au retour de Redis. La constante WP_REDIS_DISABLED ou la suppression du fichier object-cache.php le remet en ligne sans cache.

Conclusion

Le cache d’objets persistant fait gagner du temps là où WordPress travaille vraiment : administration, boutique, comptes, recherche. Il ne remplace ni le cache de pages, ni une base de données saine, ni un hébergement correct.

Avant de l’activer, posez trois réglages : une base Redis par site, une limite de mémoire avec une politique d’éviction, et une surveillance de Redis au même niveau que la base. Puis mesurez sur les pages concernées. L’histoire des caches de requêtes de WordPress le rappelle : un cache mal entretenu ne casse rien tout de suite, il s’accumule.

Sources

• WordPress Developer Resources. WP_Object_Cache
• WordPress Developer Resources (décembre 2025). Optimization
• WordPress Developer Resources. Transients
• WP-CLI. wp cache
• Make WordPress Core (6 octobre 2022). New cache Site Health checks in WordPress 6.1
• Make WordPress Core, Jonny Harris (7 octobre 2022). Improvements to WP_Query performance in 6.1
• Make WordPress Core, Jonny Harris (17 juillet 2023). Improvements to the Cache API in WordPress 6.3
• Make WordPress Core, Aaron Jorbin (17 novembre 2025). Consistent Cache Keys for Query Groups in WordPress 6.9
• GitHub, WordPress (10 mars 2023). Cache API: Introduce new queries cache groups
• GitHub, WordPress (31 août 2025). Caching API: Use consistent cache keys for query groups
• GitHub, WordPress, Till Krüss (mars 2025). Unify timestamps of query cache keys
• GitHub, WordPress (2025). New helper functions, wp_cache_*_salted
• Search Engine Journal, Roger Montti (28 septembre 2022). WordPress 6.1 Contains Massive Improvement To Database Performance
• WordPress.org Plugins. Redis Object Cache
• GitHub, Rhubarb Group. Redis Object Cache FAQ
• Object Cache Pro. Pricing
• Object Cache Pro. Shared Instances
• Object Cache Pro. Changelog
• LiteSpeed Technologies. LSCache for WordPress, Cache settings
• WordPress.org Plugins. WP Redis
• Pantheon Docs. Enable WP-Redis [Deprecated]
• WordPress.org Plugins. SQLite Object Cache
• WordPress.org Plugins. Docket Cache
• Relay. Relay
• Redis Docs. Key eviction
• Redis Docs. Redis security
• Redis, Rowan Trollope (1er mai 2025). Redis is now available under the AGPLv3 open source license
• Linux Foundation (28 mars 2024). Linux Foundation Launches Open Source Valkey Community
• Redis (3 octobre 2025). Security Advisory: CVE-2025-49844
• Amazon Web Services. Comparing node-based Valkey, Memcached, and Redis OSS clusters
• WordPress VIP Documentation. Object cache
• Kinsta Docs. Redis Caching
• Cloudways, Abdul Rehman (mars 2023). A Smarter Way to Flush Your Object Cache on Cloudways
• WordPress.org Support Forums (2025). Serious Redis Object Cache Bug
• Wetopi, Joan Vega (décembre 2024). Redis Object Cache for WordPress
• WordPress.org Plugins. Query Monitor
• Make WordPress Core, Paul Bearne (18 juin 2024). Options API: Disabling autoload for large options
• WordPress VIP Documentation. Autoloaded options
• WordPress VIP Documentation (octobre 2025). Code deployment and cache clearing
• WordPress Developer Resources. wp_get_environment_type()
• WordPress Developer Resources. WP_Site_Health::should_suggest_persistent_object_cache()
• WordPress.org News (1er novembre 2022). WordPress 6.1 “Misha”
• GitHub, Rhubarb Group. Redis Object Cache README
• GitHub, Redis. redis.conf
• Redis Docs. SELECT
• Redis Docs. INFO
• WordPress.org Plugins. W3 Total Cache
• WordPress.org Plugins. Memcached Object Cache
• GitHub, Automattic. wp-memcached
• Pantheon Docs. Enable Object Cache Pro for WordPress
• GitHub, CacheWerk. Relay
• PHP Manual. APCu, Runtime Configuration
• Query Monitor. Cache hit rate

---

LaFactory conçoit, développe et maintient des sites WordPress et WooCommerce, et développe ses propres plugins. Parlons de votre projet WordPress.