Performance WordPress : le cache object Redis qui change tout pour 8 € par mois

Je mesure les performances WordPress de mes clients depuis 2015. Et s’il y a un seul changement technique qui revient systématiquement comme le meilleur rapport coût/impact, c’est l’activation du cache object Redis. Pas le cache de page (ça, tout le monde le fait déjà). Pas un CDN (utile, mais ça ne règle pas le problème de fond). Non : le cache object, celui qui stocke en mémoire vive les résultats des requêtes à la base de données pour éviter de les relancer à chaque chargement.

Sur un WordPress avec quelques plugins, des champs ACF et un thème un peu costaud, chaque page génère entre 30 et 120 requêtes SQL. Sur WooCommerce, on dépasse souvent les 200. Sans cache object, chaque visiteur déclenche ce festival de requêtes. Avec Redis, la majorité de ces requêtes sont servies depuis la RAM en moins d’une milliseconde. Le résultat est immédiat : le serveur respire, le TTFB chute, et le site tient la charge.

Je vais vous expliquer concrètement comment ça fonctionne, combien ça coûte, comment l’installer, et surtout dans quels cas ça vaut le coup (spoiler : pas toujours).

Qu’est-ce que le cache object et pourquoi WordPress en a besoin

WordPress utilise une couche d’abstraction appelée WP_Object_Cache pour stocker temporairement les résultats de requêtes fréquentes. Par défaut, ce cache ne dure que le temps d’une requête HTTP : une fois la page servie, tout est oublié. Au prochain visiteur, WordPress relance exactement les mêmes requêtes SQL pour récupérer les mêmes options, les mêmes métadonnées, les mêmes termes de taxonomie.

C’est un gaspillage considérable. Sur un site avec 20 plugins actifs, la table wp_options est sollicitée des dizaines de fois par page. Chaque appel à get_option(), chaque requête sur les métadonnées utilisateur ou les transients passe par la base de données. Multipliez ça par 50 visiteurs simultanés, et votre serveur MySQL commence à transpirer.

Le cache object persistant résout ce problème en stockant ces résultats dans un système de cache externe, comme Redis ou Memcached, qui survit entre les requêtes HTTP. Quand un visiteur charge une page, WordPress vérifie d’abord si la donnée existe dans le cache. Si oui, elle est servie en 0,1 à 0,5 ms depuis la RAM au lieu de 5 à 50 ms depuis MySQL. Si non, la requête SQL est exécutée normalement et le résultat est mis en cache pour les visiteurs suivants.

Le gain est proportionnel à la complexité du site. Un blog minimaliste avec un thème léger ne verra presque pas la différence. Un site avec ACF Pro, WPML, WooCommerce et Yoast SEO verra une transformation spectaculaire. J’ai documenté le phénomène en détail dans mon guide complet pour créer un site WordPress en 2026 : plus un site grossit en fonctionnalités, plus le cache object devient indispensable.

Redis vs Memcached : le match pour WordPress en 2026

Deux technologies dominent le cache object : Redis et Memcached. En 2026, le débat est quasiment tranché pour WordPress, mais il reste des nuances à comprendre.

Mon verdict est simple : choisissez Redis. La persistance des données signifie que votre cache survit à un redémarrage du service. Les structures de données avancées permettent un stockage plus intelligent des objets WordPress complexes. Et surtout, l’écosystème WordPress s’est massivement orienté vers Redis : le plugin de Till Krüss est activement maintenu, documenté, et compatible avec la majorité des hébergeurs.

Memcached reste pertinent dans un seul cas : si votre hébergeur ne propose que ça. C’est de plus en plus rare en 2026, mais ça existe encore sur certaines offres mutualisées anciennes. Pour choisir le bon hébergeur avec Redis inclus, consultez mon comparatif des hébergeurs web en 2026.

L’impact réel de Redis sur les performances mesurées

Les chiffres marketing des plugins de cache sont souvent gonflés. Voici les résultats que j’ai mesurés sur trois vrais projets clients en 2025-2026, avec Query Monitor et le panel Redis Object Cache :

Projet 1 : site vitrine avec ACF Pro (12 pages, thème custom)

• Requêtes SQL par page avant Redis : 67
• Requêtes SQL par page après Redis : 12 (les 12 restantes ne sont pas cachables)
• TTFB moyen : de 480 ms à 140 ms
• Taux de hit cache : 82 %

Projet 2 : WooCommerce avec 1 800 produits et WPML

• Requêtes SQL page catégorie avant Redis : 214
• Requêtes SQL page catégorie après Redis : 38
• TTFB moyen : de 1 340 ms à 310 ms
• Taux de hit cache : 78 %

Projet 3 : blog multiauteur avec 400+ articles et Yoast SEO

• Requêtes SQL page article avant Redis : 89
• Requêtes SQL page article après Redis : 21
• TTFB moyen : de 620 ms à 180 ms
• Taux de hit cache : 76 %

Le pattern est constant : Redis élimine entre 60 et 85 % des requêtes SQL et divise le TTFB par 3 à 4. Le gain est d’autant plus visible sous charge. Lors d’un test avec 50 utilisateurs simultanés sur le projet WooCommerce, le temps de réponse moyen est passé de 4,2 secondes (avec des timeouts) à 680 ms stable. Le serveur MySQL n’a jamais dépassé 30 % de charge CPU contre 95 % sans Redis.

Ces gains se traduisent directement en meilleur référencement. Google utilise le TTFB et les Core Web Vitals comme facteurs de classement. Un TTFB sous 200 ms, c’est un signal positif fort. Pour aller plus loin sur l’optimisation SEO technique, j’ai détaillé les actions prioritaires dans mon guide SEO pour les débutants : les 10 actions qui rapportent vraiment en 2026.

Quels hébergeurs proposent Redis et à quel prix

Tous les hébergeurs ne proposent pas Redis, et ceux qui le font ne l’incluent pas toujours dans le même type d’offre. Voici l’état des lieux en avril 2026 :

Le prix d’entrée réel pour un hébergement WordPress avec Redis en France tourne autour de 8 € HT/mois. C’est le prix d’un café par semaine pour un gain de performance qui justifierait facilement 50 € de plus. Chez o2switch, il faut simplement contacter le support technique pour activer Redis sur votre compte : l’opération prend moins de 24 heures.

Attention aux offres à très bas prix : 128 Mo de RAM Redis suffisent pour un petit site vitrine, mais un WooCommerce avec 1 000+ produits et WPML aura besoin d’au moins 256 Mo, idéalement 512 Mo. Si le cache déborde, Redis commence à supprimer les entrées les plus anciennes (politique d’éviction allkeys-lru), ce qui réduit le taux de hit et donc le bénéfice.

Pour un comparatif détaillé des offres d’hébergement au-delà de Redis, consultez mon comparatif OVH, Hostinger, o2switch et Infomaniak en 2026.

Installer Redis sur WordPress : les étapes concrètes

L’installation se fait en trois phases : activer Redis côté serveur, installer le plugin WordPress, et vérifier que tout fonctionne. Voici la procédure que j’utilise sur chaque projet.

Phase 1 : activer Redis côté serveur

Sur un VPS ou un serveur dédié, l’installation est manuelle :

# Debian/Ubuntu
sudo apt update && sudo apt install redis-server php-redis
sudo systemctl enable redis-server
sudo systemctl start redis-server

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

Sur un hébergement mutualisé (o2switch, Infomaniak), vous n’avez pas accès au terminal. Contactez le support ou activez Redis depuis le panel d’administration. Chez Infomaniak, c’est dans Hébergement Web > Avancé > Cache Redis. Chez o2switch, un ticket au support suffit.

Phase 2 : installer le plugin Redis Object Cache

1. Installez le plugin Redis Object Cache par Till Krüss depuis le répertoire WordPress
2. Allez dans Réglages > Redis
3. Cliquez sur Enable Object Cache
4. Le plugin dépose automatiquement le fichier object-cache.php dans wp-content/

Si votre Redis n’est pas sur le port par défaut (6379) ou nécessite une authentification, ajoutez ces constantes dans wp-config.php avant la ligne /* That's all, stop editing! */ :

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_PASSWORD', 'votre_mot_de_passe');
define('WP_REDIS_DATABASE', 0);
define('WP_REDIS_TIMEOUT', 1);
define('WP_REDIS_READ_TIMEOUT', 1);

Phase 3 : vérifier le fonctionnement

Installez Query Monitor (plugin gratuit) pour voir en temps réel le nombre de requêtes SQL et le statut du cache object. Dans le panel Query Monitor, vous devez voir :

• Object Cache : Connected (et non « Not connected » ou « Using default »)
• Un ratio cache hits/misses supérieur à 70 % après quelques chargements de page
• Un nombre de requêtes SQL significativement réduit par rapport à avant

Si vous utilisez des mu-plugins WordPress, sachez qu’ils sont chargés avant les plugins classiques et leurs résultats bénéficient aussi du cache Redis.

Configurer et optimiser Redis pour votre cas précis

L’installation par défaut fonctionne bien, mais quelques ajustements font la différence entre un cache correct et un cache vraiment optimisé.

Limiter la mémoire Redis

Par défaut, Redis peut consommer toute la RAM disponible. Sur un hébergement partagé, c’est déjà limité par l’hébergeur. Sur un VPS, configurez une limite explicite dans /etc/redis/redis.conf :

maxmemory 256mb
maxmemory-policy allkeys-lru

La politique allkeys-lru (Least Recently Used) supprime les clés les moins récemment utilisées quand la mémoire est pleine. C’est le meilleur choix pour WordPress car les données les plus consultées restent en cache.

Configurer le préfixe de clé pour le multisite

Si vous gérez plusieurs sites WordPress sur le même serveur Redis, chaque site doit avoir son propre préfixe pour éviter les collisions :

// Dans wp-config.php de chaque site
define('WP_REDIS_PREFIX', 'site1_');
// ou
define('WP_REDIS_DATABASE', 0); // site 1
define('WP_REDIS_DATABASE', 1); // site 2

Exclure les groupes de cache inutiles

Certains groupes de cache ne bénéficient pas du stockage persistant. Les transients, par exemple, ont leur propre logique d’expiration qui peut entrer en conflit avec Redis. Dans la plupart des cas, laissez les réglages par défaut du plugin, mais si vous constatez des problèmes, vous pouvez exclure des groupes :

define('WP_REDIS_IGNORED_GROUPS', ['counts', 'plugins']);

Activer la compression

Pour les sites avec beaucoup de données en cache (WooCommerce, BuddyPress), activez la compression pour économiser de la RAM :

define('WP_REDIS_SERIALIZER', 'igbinary');
// Nécessite l'extension PHP igbinary

L’extension igbinary réduit la taille des objets sérialisés de 30 à 50 % par rapport à la sérialisation PHP standard. Sur un WooCommerce avec 2 000 produits, ça peut faire économiser 80 Mo de RAM Redis.

Les erreurs courantes qui sabotent votre cache Redis

J’interviens régulièrement sur des sites où Redis est installé mais ne fonctionne pas correctement. Voici les problèmes que je rencontre le plus souvent.

Erreur 1 : le fichier object-cache.php est obsolète

Le drop-in wp-content/object-cache.php doit correspondre à la version du plugin installé. Après une mise à jour du plugin Redis Object Cache, allez dans Réglages > Redis et cliquez sur Update Drop-In si le bouton apparaît. Un fichier obsolète peut provoquer des erreurs silencieuses ou un cache inactif.

Erreur 2 : un autre plugin de cache écrase le drop-in

Si vous utilisez W3 Total Cache ou LiteSpeed Cache avec leur propre module de cache object, il y a conflit. Un seul drop-in peut exister dans wp-content/. Désactivez le module object cache des autres plugins avant d’activer Redis Object Cache.

Erreur 3 : Redis tourne mais personne ne s’y connecte

Sur certains hébergeurs, Redis écoute sur un socket Unix plutôt que sur un port TCP. Si le plugin affiche « Connection refused », vérifiez auprès de votre hébergeur l’adresse exacte :

// Connexion via socket Unix
define('WP_REDIS_SCHEME', 'unix');
define('WP_REDIS_PATH', '/var/run/redis/redis.sock');

Erreur 4 : ne jamais vider le cache

Redis conserve les données même après un redémarrage du serveur. Si vous modifiez la structure de votre site (nouveau thème, migration, changement de permaliens), videz le cache Redis depuis le panel du plugin ou en ligne de commande avec redis-cli flushdb. Des données obsolètes en cache peuvent provoquer des affichages incohérents.

Erreur 5 : ignorer les avertissements de mémoire

Dans le panel Redis Object Cache, surveillez le Memory Usage. Si vous êtes régulièrement au-dessus de 90 % de la mémoire allouée, le taux d’éviction augmente et les performances se dégradent. Soit vous augmentez la RAM Redis, soit vous optimisez ce qui est mis en cache.

Redis et WooCommerce : le cas particulier du e-commerce

WooCommerce est le cas d’usage où Redis brille le plus, mais aussi celui qui demande le plus d’attention. Le problème spécifique du e-commerce, c’est que beaucoup de pages ne sont pas cachables au niveau page : le panier, le tunnel de commande, le compte client. Ces pages dynamiques dépendent entièrement de la base de données.

C’est exactement là que le cache object prend tout son sens. Même sur une page panier qui ne peut pas être mise en cache de page, Redis accélère toutes les requêtes sous-jacentes : les options du site, les métadonnées des produits, les taux de TVA, les zones de livraison. Sur un WooCommerce typique, 60 à 70 % des requêtes SQL d’une page panier sont des lectures répétitives parfaitement cachables par Redis.

Quelques précautions spécifiques à WooCommerce :

• Ne cachez pas les sessions WooCommerce dans Redis sauf si vous avez suffisamment de RAM. Les sessions utilisateur consomment beaucoup de mémoire et expirent rapidement. Laissez-les dans la base de données ou utilisez un plugin dédié comme WP Native PHP Sessions
• Surveillez la taille du cache pendant les pics de trafic (soldes, Black Friday). Un WooCommerce avec 5 000 produits et 500 visiteurs simultanés peut facilement remplir 512 Mo de cache Redis
• Testez le tunnel de commande après activation de Redis. Certains plugins de paiement stockent des tokens temporaires via les transients WordPress ; vérifiez que le processus de paiement fonctionne toujours correctement

Si vous envisagez une architecture plus radicale pour la performance, j’ai analysé l’approche WordPress headless avec Next.js qui découple complètement le front-end. Mais pour 95 % des boutiques WooCommerce, Redis reste la solution la plus pragmatique.

Quand Redis est inutile (et ce qu’il faut faire à la place)

Redis n’est pas une solution universelle. Voici les cas où je déconseille l’investissement :

Un blog simple avec peu de plugins. Si votre site génère moins de 30 requêtes SQL par page et que votre TTFB est déjà sous 300 ms, Redis n’apportera qu’un gain marginal. Concentrez-vous plutôt sur un bon cache de page (LiteSpeed Cache si votre hébergeur utilise OpenLiteSpeed, WP Super Cache sinon) et sur l’optimisation des images.

Un site entièrement statique ou avec cache de page à 100 %. Si chaque page est servie depuis le cache de page et que vos visiteurs ne voient jamais de contenu dynamique, les requêtes SQL ne sont déjà plus exécutées pour la majorité du trafic. Redis serait redondant. Pour les sites purement statiques, un générateur statique comme Astro ou Hugo est souvent plus pertinent qu’un WordPress avec des couches de cache.

Un problème de performance lié aux images ou au JavaScript. Redis accélère le back-end (TTFB, réponse serveur). Si votre site est lent à cause d’images non optimisées de 3 Mo, de polices web non préchargées, ou de 2 Mo de JavaScript en render-blocking, Redis ne changera rien à l’expérience utilisateur perçue. Utilisez d’abord les outils de diagnostic comme PageSpeed Insights et WebPageTest pour identifier le vrai goulot d’étranglement.

Un hébergement trop limité en RAM. Si votre hébergeur n’offre que 128 Mo de RAM au total pour PHP, et que Redis doit partager cette enveloppe, vous risquez des erreurs out of memory côté PHP. Dans ce cas, changez d’hébergeur avant d’activer Redis.

La hiérarchie des optimisations WordPress que je recommande est la suivante : 1) un bon hébergeur avec PHP 8.2+, 2) un cache de page, 3) un CDN, 4) le cache object Redis, 5) l’optimisation du thème et des plugins. Redis se situe au quatrième niveau ; les trois premiers doivent être en place avant.

Pour poser les bonnes bases avant d’ajouter Redis, commencez par suivre les étapes de mon guide pour créer un site WordPress en 2026, et complétez avec les 10 actions SEO concrètes pour apparaître sur Google. Si votre thème pose problème, la création d’un thème enfant WordPress vous permettra de personnaliser sans casser les performances.