Object cache WordPress : Redis vs Memcached, mise en place et gains réels

Tu veux accélérer ton site sans tout refondre ? L’object cache WordPress (cache d’objets persistant) est l’un des leviers les plus efficaces pour booster la performance base WordPress. Dès les premières requêtes, tu peux réduire le temps d’exécution PHP, soulager MySQL et stabiliser le TTFB. Dans cet article, on compare Redis WordPress et Memcached WordPress, on voit comment les installer proprement, comment mesurer les gains réels et comment les optimiser selon ton contexte (vitrine, blog, WooCommerce, multisite…). Notre approche est pragmatique : on t’explique ce qui change dans la vraie vie d’un site sous charge, et comment éviter les pièges.

Dans les 200 premières lignes de code, WordPress multiplie les appels à la base (options, métadonnées, taxonomies, fragments de requêtes). Sans cache persistant WordPress, ces données sont reconstruites à chaque page. Avec un object cache, elles sont stockées en mémoire et servies instantanément : moins de requêtes SQL, moins d’I/O, et des pages plus rapides, surtout pour l’admin, les pages dynamiques et les boutiques. Que tu choisisses Redis WordPress ou Memcached WordPress, l’objectif est le même : accélérer ton site, réduire la charge DB et lisser les pics. Et oui, c’est compatible avec un cache de page statique (type proxy/CDN) : les deux se complètent.

Au passage : si tu veux une mise en œuvre 100% sereine, l’équipe WP Builders peut t’accompagner pour activer, tester et monitorer la solution la plus adaptée à ton hébergement et à ton trafic. Place au concret.

Object cache persistant : ce que c’est (et ce que ce n’est pas)

Le cache d’objets WordPress stocke en mémoire des fragments de données PHP/SQL (options, résultats de requêtes, fragments calculés) identifiés par une clé. Sans solution persistante, le cache est « non persistant » (en mémoire PHP pour la durée de la requête uniquement). Avec un moteur externe (Redis ou Memcached), les objets survivent entre les requêtes, voire entre processus, ce qui change tout sur la charge MySQL.

À ne pas confondre avec :

• Cache de page (full-page cache) : stocke une page HTML entière. Super pour les pages très statiques, moins pour l’admin ou les zones personnalisées.
• Cache navigateur/CDN : sert des copies côté client/edge. Ne remplace pas l’object cache, qui optimise la construction serveur.

La documentation WordPress décrit l’API de l’object cache. En pratique, tu installes un « drop-in » (object-cache.php) et un moteur (Redis ou Memcached). Les plugins populaires (Redis Object Cache, W3 Total Cache, LiteSpeed Cache, etc.) agissent comme interfaces de configuration et de monitoring.

Redis vs Memcached : lequel choisir pour WordPress ?

Points forts de Redis

• Persistance (RDB/AOF) possible : redémarrage sans perte de tout le cache (selon configuration).
• Fonctionnalités avancées : scripts Lua, structures de données, Pub/Sub, clustering natif.
• Observabilité riche : stats détaillées, clés, TTL, slowlog.
• Large écosystème et hébergements managés (Redis Cloud, AWS ElastiCache, etc.).

Points forts de Memcached

• Ultra-simple, mémoire uniquement, très faible latence.
• Très efficace pour des key/value volatiles et un TTL court.
• Déploiement léger, peu de paramètres à régler.

Dans la pratique WordPress

• Redis est souvent préféré pour les sites à trafic soutenu, WooCommerce, multisite, besoin de namespaces, d’outils de monitoring et d’une persistance optionnelle. La documentation Redis couvre très bien l’optimisation.
• Memcached convient très bien aux sites vitrines/blogs, aux infrastructures déjà équipées, et aux besoins minimalistes sans persistance.

Règle simple : si tu veux une meilleure observabilité, une marge d’évolution et un tuning fin, choisis Redis. Si tu veux de l’ultra-léger plug-and-play, Memcached peut faire l’affaire.

Quand activer un cache d’objets persistant ?

• Tu constates beaucoup de requêtes SQL répétitives par page (via Query Monitor).
• Le TTFB varie fortement quand le trafic monte.
• Tu utilises WooCommerce, LMS, membres, ou tout plugin très dynamique.
• Ton hébergeur limite l’IO de la base ou ton instance MySQL est partagée.
• Tu fais des imports/cron fréquents qui sollicitent les options et métadonnées.

À l’inverse, si ton site est hyper statique, un bon cache de page et un CDN suffisent parfois. Mais sur WordPress, même une page « statique » appelle options, menus, widgets… L’object cache réduit ces coûts.

Pré-requis côté serveur

• Accès à un service Redis ou Memcached (local ou managé).
• Extensions PHP : php-redis ou php-memcached (versions compatibles avec ta version PHP).
• Ressources : RAM suffisante (et swap éventuel), CPU correct, réseau local rapide si service distant.
• Accès SSH/CLI pour l’installation et le diagnostic.

Installation pas à pas

Cas 1 — Hébergement managé

Beaucoup d’hébergeurs proposent Redis/Memcached en un clic. Active le service depuis le panel, note l’hôte, le port, et installe un plugin compatible (par ex. Redis Object Cache). Teste ensuite avec Query Monitor et les métriques du plugin.

Cas 2 — VPS/serveur dédié : Redis

# Debian/Ubuntusudo apt updatesudo apt install redis-server php-redis -y# Vérifier l'étatsudo systemctl enable --now redis-serverredis-cli ping  # doit répondre PONG# (Option) Sécuriser et ajuster /etc/redis/redis.conf# - supervised systemd# - maxmemory 512mb# - maxmemory-policy allkeys-lru (ou volatile-lru)# - appendonly no (par défaut) ou yes si besoin de persistance# Redémarragesudo systemctl restart redis-server

Côté WordPress, installe le plugin « Redis Object Cache » et active le drop-in. Ajoute/ajuste ces constantes dans wp-config.php :

define('WP_CACHE', true);define('WP_REDIS_HOST', '127.0.0.1');define('WP_REDIS_PORT', 6379);define('WP_REDIS_TIMEOUT', 1.0);define('WP_REDIS_READ_TIMEOUT', 1.0);// define('WP_REDIS_PASSWORD', 'mot-de-passe');// define('WP_REDIS_MAXTTL', 3600); // TTL max par défaut// define('WP_CACHE_KEY_SALT', 'exemple.com:'); // évite les collisions

Cas 3 — VPS/serveur dédié : Memcached

# Debian/Ubuntusudo apt updatesudo apt install memcached libmemcached-tools php-memcached -y# Vérifier l'étatsudo systemctl enable --now memcachedmemcached -h | head# Ajuster /etc/memcached.conf# -m 256  (mémoire en Mo)# -l 127.0.0.1# -p 11211sudo systemctl restart memcached

Côté WordPress, utilise un plugin supportant Memcached (W3 Total Cache, LiteSpeed Cache, etc.). Si tu manipules les constantes :

define('WP_CACHE', true);// Selon le plugin utilisé, renseigne l'hôte/port Memcached dans les réglages.

Configuration WordPress : options clés

• WP_CACHE doit être à true.
• Salt de clés (WP_CACHE_KEY_SALT) recommandé, surtout multi-instances.
• TTL par défaut raisonnable (ex. 1 heure) et plus court sur les données très volatiles.
• Groupes non persistants (runtime uniquement) pour les données hyper volatiles (sessions, jetons) : la plupart des plugins Redis/Memcached proposent cette option.
• Compression possible (Redis, selon plugin) pour économiser la RAM, au prix d’un peu de CPU.

Mesurer les gains réels (avant/après)

Pas de magie sans mesures. Conserve un baseline avant activation :

• Queries/page via Query Monitor (onglet DB queries).
• TTFB via DevTools ou curl -w "%{time_starttransfer}\n".
• Temps moyen sur 10 requêtes de la même URL non mise en cache de page.
• CPU/RAM du serveur (top/htop), latence DB.

Après activation du cache persistant :

• Observe le hit ratio (Redis/Memcached) et la baisse des requêtes SQL.
• Compare TTFB et temps moyen sur une série de 10 requêtes.
• Teste des pages dynamiques (compte client, panier, recherche).

Si tu vois une baisse de 30–70% des requêtes SQL et un TTFB plus stable sous charge, c’est gagné. Les gains dépendent du thème, des plugins et du trafic. L’important est d’itérer : activer, mesurer, ajuster.

Tuning Redis/Memcached pour WordPress

TTL et politique d’éviction

• TTL (Time To Live) trop long = risque de données périmées. Trop court = moins de hits. Commence à 3600 s puis ajuste selon les pages/objets.
• maxmemory (Redis) ou -m (Memcached) : réserve assez de RAM pour éviter les évictions prématurées.
• Eviction policy (Redis) : allkeys-lru ou volatile-lru selon que tu poses un TTL partout ou non.

Groupes d’objets et exclusions

• Exclus les groupes très volatiles (sessions, nonces) des caches persistants.
• Conserve en cache les options, menus, fragments de requêtes lourdes, transients calculés.

Compression et sérialisation

• Redis + compression (LZ4/ZSTD) via plugin peut sauver de la RAM. Sur CPU limité, teste l’impact.
• Memcached sérialise en PHP par défaut. Sur des objets très gros, vérifie le chunking.

Clusters et services managés

• Sur forte charge, Redis cluster/sharding peut répartir la charge. Attention à la latence réseau si service distant.
• Sur PaaS/Cloud, active les métriques/alertes (hits, evictions, latency, reconnects).

Cas pratiques (WooCommerce, multisite, import)

WooCommerce

• Panier et session : souvent exclus du cache persistant, mais conservés en cache non persistant.
• Produits : mets en cache les requêtes de catalogue, filtres, attributs ; purge au changement de stock/prix.
• Checkout : prudence, c’est une zone critique. Garde la cohérence avant tout.

Multisite

• Utilise un key salt par site pour éviter les collisions.
• Sur Redis, utilise des prefixes propres par blog_id.

Import/cron

• Pendant un import massif, tu peux temporairement réduire le TTL ou désactiver certains groupes pour éviter d’inonder la RAM d’objets éphémères.
• Ensuite, purge ciblée et retour à la configuration nominale.

Outils de diagnostic et bonnes pratiques

• Query Monitor : visualise requêtes SQL, temps d’exécution, détail du cache d’objets.
• WP-CLI : certaines extensions exposent des commandes (wp redis info, wp redis flush…).
• Logs Redis : redis-cli info, redis-cli monitor, slowlog get.
• Memcached tools : memcached-tool 127.0.0.1:11211 stats.
• Observation continue : hits/misses, evictions, latence réseau, fragmentation mémoire.

Erreurs fréquentes et pièges à éviter

• Confondre cache de page et cache d’objets : l’un n’annule pas l’autre. Combine-les intelligemment.
• Pas de clé de salage : collision entre environnements/staging. Ajoute WP_CACHE_KEY_SALT.
• TTL à 0 partout : mémoire saturée, evictions, perf erratique.
• Purger à tout-va : mieux vaut des purges ciblées sur les groupes concernés.
• Oublier la sécurité : Redis ouvert sur Internet sans auth/ACL est un vrai risque. Restreins l’accès, utilise un mot de passe ou un socket Unix.

Plan d’implémentation en 7 étapes (checklist)

1. Mesurer l’état initial (queries, TTFB, CPU/RAM).
2. Choisir Redis ou Memcached selon besoins et hébergeur.
3. Installer le service et l’extension PHP.
4. Activer le drop-in/plug-in WordPress.
5. Configurer TTL, groupes exclus, salt, sécurité.
6. Tester et comparer avant/après sur pages clés.
7. Monitorer et ajuster (tuning mémoire, TTL, purge ciblée).

Active le cache persistant sans risque

Nos experts configurent, testent et monitorent Redis ou Memcached pour des gains mesurables dès aujourd’hui.

Voir nos offres de maintenance

Exemples de configuration

Redis avec socket Unix (latence minimale)

# redis.confunixsocket /var/run/redis/redis-server.sockunixsocketperm 770# www-data doit être dans le groupe redissudo usermod -aG redis www-datasudo systemctl restart redis-server

// wp-config.phpdefine('WP_REDIS_PATH', 'https://cdn.wp-builders.tech/var/run/redis/redis-server.sock');// Pas besoin d'hôte/port dans ce cas

Memcached : ajuster la mémoire et la fragmentation

# /etc/memcached.conf-m 512-I 2m   # taille max d'un item# Sur des objets volumineux, augmente -I prudemment

Monitoring continu : savoir si le cache travaille pour toi

• Hit ratio sur 5/15 min, pas seulement en instantané.
• Evictions : si elles montent, augmente la mémoire ou réduis le TTL.
• Latence : réseau (si service distant) et temps moyen de réponse du cache.
• Top keys : détecte les clés « chaudes » susceptibles d’éviction.
• Alertes : configure des seuils sur RAM, latence et hit ratio pour agir avant l’impact utilisateur.

Et la maintenance dans tout ça ?

Un cache d’objets bien réglé, c’est de la sérénité au quotidien : moins de charge serveur, des temps de réponse stables, un back-office plus fluide. Mais son efficacité dépend d’un ensemble : version de PHP, qualité du code, base optimisée, cron, CDN, cache de page. Chez WP Builders, on prend l’écosystème en entier pour te livrer des gains réels et durables, et pas juste un score de labo. On documente la config, on met des garde-fous, et on t’explique quoi faire lors d’un pic, d’un import ou d’une refonte.

Conclusion : Redis ou Memcached, choisis la méthode… et mesure

Tu peux obtenir des gains impressionnants avec l’object cache WordPress : réduction des requêtes SQL, TTFB lissé, admin plus réactif, meilleure performance base WordPress. Redis apporte des capacités d’observabilité et d’évolutivité supérieures ; Memcached offre une simplicité redoutable. L’essentiel est d’installer proprement, de mesurer avant/après, puis d’ajuster TTL, mémoire et exclusions selon ton site.

Besoin d’un coup de main pour franchir le cap avec zéro risque ? Notre équipe peut auditer ton environnement, proposer la bonne architecture, déployer et monitorer la solution adaptée (Redis ou Memcached), puis t’accompagner sur la durée avec un contrat de maintenance clair.

Ressources utiles

• API Object Cache WordPress : documentation officielle
• Optimiser et diagnostiquer Redis : guide développeur Redis