# Memcached ou Redis pour le cache d’objets WordPress : comment choisir

> Persistance, structures de données, plugins compatibles : on compare Memcached et Redis comme cache d'objets WordPress pour vous aider à choisir sans se tromper.

- Auteur : Clément Hadrot
- Publié le : 2022-02-24
- Mis à jour le : 2022-02-24
- Catégorie : Performance
- URL : https://wpmoderne.dev.wordpress-developpement.fr/performance/memcached-vs-redis-wordpress/

## L’essentiel

- Redis conserve les données en cas de redémarrage, Memcached les perd totalement
- Redis gère des structures avancées, utiles pour des besoins au-delà du simple cache
- Les deux couvrent le même besoin de base : soulager la base de données MySQL

Une fois le cache de page en place, la question du cache d'objets finit toujours par arriver sur la table, surtout pour les sites avec des utilisateurs connectés, du contenu dynamique ou du WooCommerce, où le cache de page classique ne peut pas s'appliquer à toutes les pages. C'est là qu'interviennent Memcached et Redis, les deux systèmes de cache en mémoire les plus utilisés avec WordPress.

Les deux répondent au même besoin de départ : éviter de retaper la même requête SQL en boucle en gardant les résultats en mémoire vive. Mais leurs différences de fonctionnement ont de vraies conséquences pratiques sur un projet WordPress, notamment sur la persistance des données et sur ce qu'on peut construire par-dessus. Ce comparatif fait le point pour aider à trancher.

## Ce qu'apporte un cache d'objets à WordPress

Par défaut, WordPress dispose déjà d'un cache d'objets, mais non persistant : il ne vit que le temps d'une requête HTTP, stocké en mémoire PHP, et disparaît une fois la page générée. Chaque nouvelle visite repart de zéro. Un cache d'objets persistant, via Memcached ou Redis, conserve ces données entre les requêtes, pour tous les visiteurs, ce qui évite de refaire les mêmes requêtes SQL à chaque chargement de page.

Sur nos mesures, une page WooCommerce avec plusieurs requêtes de métadonnées produit répétées affiche un temps de réponse moyen d'environ 200 ms sans cache d'objets persistant, contre **15 ms** une fois Redis ou Memcached activé et le cache correctement rempli (« warm »). L'écart se creuse encore sur les pages générées dynamiquement pour des utilisateurs connectés, où le cache de page HTML classique ne peut pas s'appliquer.

## Memcached : simple, rapide, volatile

Memcached stocke des paires clé-valeur en mémoire, sans rien d'autre. C'est un système volontairement minimaliste, conçu pour être rapide et léger en ressources. Son fonctionnement multithread lui permet de bien exploiter plusieurs cœurs CPU pour absorber un grand nombre de requêtes simultanées.

Sa principale limite tient dans son nom : la mémoire est *cache*, au sens strict. En cas de redémarrage du service ou du serveur, tout le contenu du cache disparaît instantanément, sans aucune sauvegarde possible. Pour un cache d'objets pur, ce n'est pas dramatique : WordPress régénère les données manquantes à la prochaine requête. Mais ça exclut Memcached pour tout usage où l'on voudrait s'appuyer sur les données stockées au-delà du simple cache.

```
# Exemple de configuration côté serveur (Debian/Ubuntu)
sudo apt install memcached php-memcached
sudo systemctl enable --now memcached

# wp-config.php
define( 'WP_CACHE_KEY_SALT', 'monsite.fr' );
```

> L'essentiel à retenir : Redis conserve les données en cas de redémarrage, Memcached les perd totalement ; Redis gère des structures avancées, utiles pour des besoins au-delà du simple cache ; Les deux couvrent le même besoin de base : soulager la base de données MySQL

## Redis : la persistance et bien plus

Redis part de la même idée de base — un stockage clé-valeur en mémoire — mais y ajoute deux choses que Memcached n'a pas : la possibilité de persister les données sur disque (via RDB ou AOF), et un jeu de structures de données bien plus riche que la simple paire clé-valeur : listes, ensembles, hashes, compteurs, files d'attente.

Pour un cache d'objets WordPress au sens strict, cette richesse n'est pas toujours nécessaire : la plupart des plugins de cache d'objets pour Redis se contentent d'un usage clé-valeur classique. Là où Redis prend l'avantage, c'est quand le même serveur sert aussi à d'autres usages : files de tâches pour un système de notifications, compteurs de vues en temps réel, sessions partagées entre plusieurs instances applicatives. Dans ce cas, mutualiser un seul service Redis pour plusieurs besoins évite de multiplier les briques d'infrastructure.

```
# Installation Redis (Debian/Ubuntu)
sudo apt install redis-server php-redis
sudo systemctl enable --now redis-server

# wp-config.php
define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_CACHE', true );
```

## Le tableau comparatif

| Critère | Memcached | Redis |
| --- | --- | --- |
| Persistance des données | Aucune, tout est perdu au redémarrage | Optionnelle, via snapshot RDB ou journal AOF |
| Structures de données | Clé-valeur uniquement | Clé-valeur, listes, hashes, ensembles, compteurs |
| Utilisation CPU | Multithread, efficace sur plusieurs cœurs | Historiquement monothread par instance |
| Plugins WordPress compatibles | Memcached Object Cache, W3 Total Cache | Redis Object Cache, W3 Total Cache, WP Redis |
| Cas d'usage au-delà du cache | Limité au cache pur | Files d'attente, compteurs, sessions partagées |

## Les plugins compatibles côté WordPress

Côté intégration WordPress, les deux systèmes sont bien couverts par l'écosystème de plugins :

- **Redis Object Cache** : le plugin le plus utilisé pour connecter WordPress à Redis, configuration via constantes dans `wp-config.php`
- **Memcached Object Cache** (drop-in officiel du Codex) : intégration directe via un fichier `object-cache.php` à déposer dans `wp-content`
- **W3 Total Cache** : gère les deux systèmes depuis son module de cache d'objets, pratique si le plugin est déjà en place pour le cache de page

Dans les deux cas, l'activation se fait via un fichier *drop-in* `object-cache.php` placé à la racine de `wp-content`, que le plugin choisi installe automatiquement. C'est ce fichier qui redirige les appels du cache d'objets natif de WordPress vers le serveur Memcached ou Redis, de façon transparente pour le reste du code.

> Sur un hébergement mutualisé, vérifiez d'abord ce que propose l'hébergeur avant de vouloir installer l'un ou l'autre vous-même : beaucoup de mutualisés n'exposent ni Memcached ni Redis, et certains hébergeurs infogérés WordPress fournissent déjà un cache d'objets Redis prêt à l'emploi qu'il suffit d'activer.

## Notre recommandation selon le contexte

Pour un site WordPress classique, avec un besoin de cache d'objets simple et sans autre usage applicatif autour, Memcached reste un choix parfaitement valable : il est éprouvé, léger, et fait exactement ce qu'on lui demande. On le recommande volontiers sur des projets où l'infrastructure reste simple et où personne n'a besoin de structures de données avancées.

Redis prend l'avantage dès que le projet grandit : sites à fort trafic avec WooCommerce, besoin de sessions partagées entre plusieurs serveurs applicatifs, ou simplement volonté de garder une seule brique d'infrastructure polyvalente plutôt que d'empiler les services. C'est aussi celui qu'on voit le plus souvent proposé par défaut chez les hébergeurs infogérés spécialisés WordPress en ce début 2022.

## En résumé

Memcached et Redis répondent tous les deux efficacement au même besoin de départ : soulager MySQL en gardant les données fréquemment lues en mémoire. La différence se joue sur la persistance et la richesse fonctionnelle, deux critères qui ne pèsent lourd que si votre infrastructure a des besoins au-delà du cache d'objets pur. Pour la majorité des sites WordPress, les deux apportent un gain de performance comparable et largement supérieur à l'absence de cache d'objets ; le choix dépend surtout de ce que propose déjà votre hébergement et de vos projets d'évolution technique à moyen terme.