Qu'est-ce qu'un cache d'objets ? Redis et Memcached pour WordPress expliqués

Un cache d'objets, souvent désigné par son nom anglais object cache, garde en mémoire les résultats des requêtes à la base de données, pour que WordPress n'ait pas à aller les rechercher dans la base la fois suivante. Ça n'a l'air de rien. Sur les boutiques, les sites de membres et tout ce qui compte beaucoup d'utilisateurs connectés, c'est pourtant souvent ce qui fait la plus grande différence sur le temps de chargement. WordPress embarque bien son propre cache d'objets, mais il oublie tout à la fin de chaque chargement de page. Ce n'est qu'avec Redis ou Memcached en coulisses qu'il devient un cache d'objets persistant, qui conserve les données sur de nombreuses requêtes. Dans cet article, vous verrez en détail comment cela fonctionne, ce qui distingue Redis de Memcached, quand l'effort en vaut la peine et quelles erreurs éviter lors de la mise en place.

Qu'est-ce qu'un cache d'objets dans WordPress ?

Chaque fois que quelqu'un ouvre une page de votre site, WordPress l'assemble à partir d'une multitude de morceaux. Il charge les réglages du site, les menus, les widgets, le contenu de l'article, les données de l'auteur, les catégories, les étiquettes et tout ce dont vos extensions ont besoin en plus. Presque tout cela se trouve dans la base de données (MySQL ou MariaDB). Une page ordinaire atteint vite 50 à 150 requêtes à la base de données, et nettement plus avec WooCommerce et quelques grosses extensions. Beaucoup de ces requêtes posent exactement la même question à chaque visite : comment s'appelle le site ? Quelles extensions sont actives ? À quoi ressemble le menu principal ?

Un cache d'objets retient les réponses à ce genre de questions. WordPress regarde d'abord dans le cache, et ce n'est que s'il n'y trouve rien que la requête part vers la base de données. Le résultat est ensuite rangé dans le cache, et la fois suivante il est disponible tout de suite. Le nom vient du fait que WordPress n'y stocke pas des pages finies, mais des objets de données individuels : un article, une liste d'options, les métadonnées d'un utilisateur.

Imaginez une petite note collée à côté de votre clavier. Au lieu de fouiller chaque fois dans vos classeurs, vous jetez d'abord un œil à la note. Pour une seule question, le gain de temps est minime. Quand la même question revient mille fois par jour, il devient énorme.

Comment fonctionne le cache d'objets de WordPress ?

Depuis de nombreuses années, WordPress dispose de sa propre classe pour le cache d'objets, WP_Object_Cache. Le cœur de WordPress et de nombreuses extensions s'en servent via des fonctions comme wp_cache_get() et wp_cache_set(). Le hic : sans logiciel supplémentaire, ce cache ne vit que le temps d'un seul chargement de page. Dès que la page a été envoyée, la mémoire se vide, et le visiteur suivant repart de zéro.

Ce cache non persistant n'est pas inutile pour autant, car il évite d'envoyer deux fois la même requête pendant un chargement de page. Mais ça ne devient vraiment intéressant qu'avec un cache d'objets persistant. Ce cache repose sur un fichier nommé object-cache.php, placé dans le dossier wp-content. WordPress le détecte automatiquement au démarrage et utilise alors, à la place de son stockage temporaire, un service externe comme Redis ou Memcached. Les données y restent d'un chargement de page à l'autre, jusqu'à ce qu'elles expirent, qu'elles changent ou que la mémoire soit pleine. Ce fichier, vous n'avez pas à l'écrire. Des extensions comme Redis Object Cache le fournissent et le placent au bon endroit quand vous les activez.

Un effet secondaire que beaucoup ignorent concerne les transients. Ce sont des valeurs mises en cache avec une date d'expiration, que les extensions utilisent volontiers, par exemple pour stocker les réponses d'API externes. Sans cache d'objets persistant, les transients atterrissent dans la table wp_options et la font grossir avec le temps. Avec Redis ou Memcached, ils passent en mémoire, et la base de données reste plus légère.

Cache d'objets, cache de page et OPcache : quelle différence ?

Dès qu'on parle de WordPress et de mise en cache, trois termes reviennent vite, et on les confond facilement. Ils travaillent à des niveaux différents et se complètent au lieu de se remplacer.

• Cache de page : enregistre la page complète, toute prête, en HTML et la sert sans même démarrer WordPress. C'est le principe de WP Rocket, LiteSpeed Cache ou WP Super Cache, par exemple. Rien n'est plus rapide, mais seulement tant que tous les visiteurs voient la même page.
• Cache d'objets : stocke des résultats individuels issus de la base de données. WordPress s'exécute toujours à chaque requête, mais doit interroger la base de données bien moins souvent.
• OPcache : n'a rien à voir avec vos données. Il évite à PHP de relire et de recompiler les fichiers de WordPress à chaque requête. Aujourd'hui, il est déjà actif sur presque tous les hébergements.

Le point essentiel : un cache de page n'aide que pour les pages identiques pour tout le monde. Dès que quelqu'un se connecte, ajoute un produit au panier ou travaille dans l'administration, il est contourné. C'est précisément là que le cache d'objets prend le relais. Pour un blog lu presque uniquement par des visiteurs anonymes, un bon cache de page apporte donc davantage. Pour une boutique, une plateforme de formation ou un forum, le cache d'objets est souvent le levier le plus puissant.

Redis vs Memcached : quel cache d'objets choisir pour WordPress ?

Les deux systèmes gardent les données en mémoire et les stockent sous forme de simples paires associant une clé à une valeur. Comme cache d'objets, l'un comme l'autre est assez rapide. Les différences se cachent dans les détails.

Redis est aujourd'hui le choix habituel pour WordPress. Il sait stocker bien plus que des clés et des valeurs, par exemple des listes, des hashes et des sets, et si vous le souhaitez, il écrit son contenu sur le disque pour que le cache survive à un redémarrage. S'y ajoutent la réplication, une gestion des droits plus fine et un vaste écosystème. Pour WordPress, il existe en plus Redis Object Cache, une extension très répandue et bien maintenue. Après un changement de licence chez Redis en 2024, Valkey a vu le jour : un fork libre placé sous l'égide de la Linux Foundation, que de nombreux hébergeurs utilisent désormais. Pour WordPress, il se comporte exactement comme Redis, et en général vous ne remarquerez aucune différence.

Memcached est plus ancien et volontairement simple. Il ne connaît que des clés et des valeurs, ne stocke rien de façon permanente et perd tout son contenu à chaque redémarrage. En contrepartie, il exploite plusieurs cœurs de processeur à la fois et se répartit très facilement sur plusieurs serveurs. Une limite se fait sentir de temps en temps avec WordPress : par défaut, une entrée ne peut pas dépasser 1 Mo. Avec de très grosses options, comme les réglages surchargés de certains constructeurs de pages, cela peut poser problème.

Notre conseil : si votre hébergeur propose les deux, prenez Redis. Si seul Memcached est disponible, pas d'inquiétude, il suffit largement comme cache d'objets. Ce qui compte bien plus que le choix entre les deux, c'est qu'un cache d'objets persistant tourne vraiment et qu'il soit configuré correctement. Il existe d'ailleurs un troisième candidat, APCu, un cache intégré directement à PHP. Il se passe de service séparé, mais ne fonctionne que sur un seul serveur et joue un rôle plus modeste en pratique.

Quand utiliser un cache d'objets persistant ?

Un cache d'objets n'a rien d'une solution miracle. Son apport dépend du nombre de requêtes qui passent à côté du cache de page pour arriver directement chez WordPress, et du travail que la base de données doit fournir pour y répondre. L'effet se fait particulièrement sentir pour :

• Les boutiques WooCommerce, car le panier, la validation de commande et le compte client ne sortent jamais du cache de page.
• Les sites de membres, les plateformes de formation et les forums où beaucoup d'utilisateurs sont connectés.
• Les rédactions où plusieurs personnes travaillent en même temps dans l'administration.
• Les sites qui comptent beaucoup d'extensions stockant leurs données dans des options et des transients.
• Les gros sites avec des milliers d'articles, de termes ou d'utilisateurs.

WordPress vous donne d'ailleurs lui aussi un indice. Depuis la version 6.1, l'écran Santé du site, dans le menu Outils, recommande un cache d'objets persistant dès que votre site dépasse certains seuils, par exemple plus de 1 000 articles, commentaires ou utilisateurs.

À l'inverse, un cache d'objets apporte peu à un petit site vitrine de dix pages, visité presque uniquement par des anonymes et déjà équipé d'un bon cache de page. Là, le cache de page répond de toute façon à presque toutes les requêtes, avant même que WordPress démarre.

Comment configurer un cache d'objets avec Redis dans WordPress ?

La marche à suivre dépend de votre hébergement. Chez beaucoup d'hébergeurs infogérés, Redis est déjà disponible et s'active d'un simple clic dans l'espace client, et certains configurent même tout pour vous. En cas de doute, posez rapidement la question au support avant d'installer quoi que ce soit. Sur votre propre serveur, cela se passe généralement ainsi :

1. Installez et démarrez Redis, sous Debian ou Ubuntu par exemple avec le paquet redis-server.
2. Installez le module phpredis pour PHP (paquet php-redis) afin que PHP puisse communiquer avec Redis. L'extension Redis Object Cache embarque aussi Predis, une variante qui fonctionne sans aucun module, mais elle est nettement plus lente.
3. Ajoutez les paramètres de connexion dans wp-config.php, avant la ligne qui marque la fin des modifications.
4. Installez l'extension Redis Object Cache et activez le cache d'objets dans ses réglages. Cela crée le fichier object-cache.php.

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_PREFIX', 'mysite_' );
define( 'WP_REDIS_MAXTTL', 86400 );

Définissez toujours le préfixe dès que plusieurs sites partagent la même instance Redis. Sans lui, deux installations peuvent écraser mutuellement leurs données, et cela provoque des erreurs vraiment étranges. Si vous préférez la ligne de commande, la dernière étape se fait avec wp plugin install redis-cache --activate, puis wp redis enable. Pour les grosses boutiques, il existe aussi une solution payante, Object Cache Pro.

Quelles sont les erreurs les plus fréquentes avec un cache d'objets ?

Un cache d'objets se met en place rapidement, mais quelques pièges reviennent sans cesse.

• Pas de limite de mémoire : sans maxmemory, Redis grossit jusqu'à ce que le serveur n'ait plus de mémoire. Avec une limite mais la politique par défaut noeviction, Redis refuse les nouvelles entrées dès que la mémoire est pleine, et WordPress se met soudain à afficher des erreurs. Pour un cache, allkeys-lru est le bon choix : Redis supprime alors tout simplement les entrées inutilisées depuis le plus longtemps.
• Redis ouvert sur Internet : Redis ne doit être joignable que sur 127.0.0.1 ou sur un réseau privé, et il doit être protégé par un mot de passe. Les instances ouvertes sur le port 6379 sont activement recherchées et détournées.
• Données périmées après des modifications directes : si vous modifiez des données directement dans la base, par exemple avec phpMyAdmin ou lors d'un import, vous passez à côté du cache. WordPress continue alors d'afficher les anciennes valeurs. Videz le cache ensuite, soit dans les réglages de l'extension, soit avec wp cache flush.
• Un object-cache.php oublié après un déménagement : si vous migrez vers un serveur sans Redis, le fichier reste parfois dans le dossier wp-content. Dans le meilleur des cas, une simple notice s'affiche dans l'administration. Dans le pire, WordPress s'arrête sur une erreur fatale. Il suffit alors de supprimer le fichier par FTP.
• Redis sur un serveur distant : chaque accès au cache doit alors traverser le réseau. Avec des centaines d'accès par chargement de page, la latence grignote une partie du gain. Idéalement, Redis tourne sur le même serveur, ou au moins dans le même centre de données.

maxmemory 256mb
maxmemory-policy allkeys-lru

Ces deux lignes dans redis.conf suffisent pour la plupart des sites. La quantité de mémoire nécessaire dépend de la taille du site. Pour une boutique classique, 256 Mo, c'est un bon point de départ.

Comment vérifier que le cache d'objets fonctionne ?

Il y a plusieurs façons de voir si le cache fait vraiment son travail :

• Dans l'extension : Redis Object Cache indique dans ses réglages si la connexion est établie et affiche une petite statistique des succès (hits) et des échecs (misses).
• En ligne de commande : wp cache type vous indique quel cache d'objets est actif. Si la réponse est Default, aucun cache persistant ne tourne.
• Avec Query Monitor : cette extension gratuite affiche, pour chaque chargement de page, le taux de succès du cache d'objets et le nombre de requêtes à la base de données. Comparez une fois les valeurs avec et sans cache, la différence est souvent plus grande qu'on ne le pense.
• Directement dans Redis : redis-cli info stats renvoie entre autres keyspace_hits et keyspace_misses. Si le taux de succès reste bas même après quelques heures de fonctionnement, c'est en général que la configuration pose problème, par exemple une limite de mémoire trop faible.

Comment InspectWP vous aide à évaluer la mise en cache de votre site

Un cache d'objets travaille sur le serveur, on ne le voit donc pas directement de l'extérieur. Son effet, en revanche, se voit très bien. Le rapport InspectWP mesure entre autres le Time to First Byte (TTFB), soit le temps qu'il faut au serveur pour que le premier octet de la page arrive. InspectWP signale les valeurs supérieures à 800 millisecondes par un avertissement, et c'est exactement là qu'un cache d'objets aide quand la page ne vient pas du cache de page. InspectWP détecte aussi les extensions utilisées pour la mise en cache, dont Redis Object Cache, grâce au court commentaire que l'extension laisse par défaut dans le code source. Avec les informations sur l'hébergeur, le serveur et la version de PHP, vous voyez vite si la mise en cache d'un site a encore de la marge de progression.