Redis, Valkey ou Memcached : quel cache objet pour un WordPress e-commerce en 2026 ?

Pour une boutique WooCommerce active, choisissez en priorité Valkey ou Redis si votre hébergeur fournit une instance isolée, supervisée et compatible avec votre extension WordPress. Memcached convient si vous avez seulement besoin d’un cache objet volatil et simple.

Un cache objet persistant réduit les lectures répétées de MySQL ou MariaDB pour des données telles que les options WordPress, les résultats de requêtes, les transients et certains objets WooCommerce. Il ne remplace ni l’optimisation de la base de données ni le cache de pages, qui reste particulièrement utile pour les fiches produits consultées anonymement.

Choisir le moteur adapté

Valkey est un projet open source issu du code de Redis 7.2.4 et hébergé par la Linux Foundation. Il utilise le protocole Redis et vise la compatibilité avec les clients et usages courants de Redis : c’est un choix pragmatique pour un nouveau déploiement compatible avec ce protocole.

Redis est cohérent si votre hébergeur ou votre infrastructure le fournit déjà et le maîtrise. Son modèle de licence a changé à partir de Redis 7.4 ; demandez donc quelle édition est proposée, qui gère les mises à jour et quelle mémoire est attribuée.

Memcached stocke des paires clé-valeur en mémoire, sans persistance native : son contenu est perdu après un redémarrage. Ce fonctionnement est acceptable pour des objets facilement reconstruits, mais moins adapté si vous avez besoin de mécanismes avancés, de réplication ou d’un diagnostic fin des incidents.

Vérifier l’offre d’hébergement

Une mention telle que « Redis inclus » ne suffit pas, surtout en hébergement mutualisé. Pour un e-commerce, privilégiez une instance ou un espace mémoire clairement isolé afin de limiter les effets d’un voisin bruyant ou d’une purge que vous ne maîtrisez pas.

• Mémoire et éviction : demandez la limite, le comportement lorsque cette limite est atteinte et les alertes disponibles.
• Accès privé : le service ne doit pas être exposé publiquement sur Internet ; une authentification et un réseau interne sont attendus.
• Supervision : la latence, la mémoire utilisée, les évictions, les connexions et la disponibilité doivent être visibles ou exportables.
• Reprise : précisez si la persistance est proposée et si une perte de cache au redémarrage est acceptable.

La persistance ne doit pas faire du cache une source de vérité métier. Les commandes, paiements et stocks doivent rester dans les systèmes prévus à cet effet : un redémarrage du cache peut ralentir temporairement le site, mais ne doit ni empêcher une vente ni altérer des données.

Déployer et mesurer

Activez une seule extension de cache objet compatible avec le moteur, d’abord sur une préproduction représentative. Redis Object Cache est une extension couramment utilisée avec des serveurs compatibles Redis ; elle ne remplace pas un plugin de cache de pages.

Mesurez avant et après avec les mêmes parcours : navigation de catégorie, fiche produit, ajout au panier, connexion client et commande. Comparez les requêtes SQL, le temps de génération PHP, les erreurs applicatives et les temps de réponse élevés lors des pics ; le guide d’optimisation de WordPress rappelle que les caches persistants réduisent les requêtes répétées vers la base.

Évitez de multiplier les services ou extensions qui écrivent les mêmes clés. Si WooCommerce, un plugin de cache et l’hébergeur proposent chacun un cache objet, identifiez précisément celui qui est actif avant toute configuration.