Le cache produit dans WooCommerce : les 3 niveaux, et ce que change la 11.0

Quand un client me dit « j’ai déjà installé un cache, le site devrait être rapide », il parle presque toujours d’une seule des trois couches de cache qui coexistent sur une boutique WooCommerce. Et c’est rarement celle qui pose problème. Le mot « cache » recouvre des mécanismes très différents, qui agissent à des endroits différents et résolvent des problèmes différents.

WooCommerce 11.0 (prévu pour le 28 juillet 2026) vient justement d’activer par défaut une nouvelle forme de cache produit — mais uniquement sur les nouvelles boutiques. C’est l’occasion de remettre les idées au clair sur ces trois niveaux, et de comprendre ce que cette nouveauté change concrètement pour vous.

Niveau 1 : le page cache (cache de page)

C’est celui que tout le monde connaît, fourni par WP Rocket, LiteSpeed Cache, WP Super Cache, ou directement par votre hébergeur.

Le principe : la première fois qu’un visiteur charge une page, WordPress exécute tout le PHP, interroge la base de données, et génère le HTML final. Le plugin de cache stocke ce HTML et le ressert tel quel aux visiteurs suivants, sans réexécuter PHP. Résultat : une page quasi instantanée.

C’est très efficace… pour les pages statiques. Le problème, c’est que les pages les plus critiques de WooCommerce ne sont pas cachables : le panier, le checkout, le compte client, et toute requête AJAX (cart fragments, recherche produit, calcul de livraison) changent à chaque visiteur. C’est exactement pour ça qu’un plugin de cache ne suffit jamais à lui seul sur une boutique. Le page cache ne fait rien pour la vitesse d’exécution PHP sur les pages dynamiques.

Niveau 2 : l’object cache persistant (Redis, Memcached)

C’est le niveau le plus mal compris, et le plus utile sur une boutique à fort trafic.

WordPress dispose d’un cache d’objets interne, mais par défaut il est non persistant : il ne vit que le temps d’une seule requête, puis disparaît. Chaque nouvelle requête repart de zéro et réinterroge la base de données.

En installant un backend persistant comme Redis ou Memcached (plus un plugin type Redis Object Cache), ce cache survit entre les requêtes et est partagé entre tous les visiteurs. Les résultats de requêtes coûteuses — options, métadonnées produit, termes de taxonomie — sont gardés en mémoire au lieu d’être recalculés. Sur une boutique avec beaucoup de produits et de trafic, c’est souvent le gain le plus spectaculaire, parce qu’il accélère justement les pages dynamiques que le page cache ne touche pas.

À noter : ce cache persistant doit être correctement vidé lors des opérations massives, sinon il gonfle indéfiniment. C’est un point que j’aborde dans l’article sur les migrations WooCommerce en WP-CLI. Et garder une base saine ne se limite pas au cache : la croissance des tables d’Action Scheduler et le poids des options autochargées pèsent tout autant sur les performances.

Niveau 3 : le cache produit en mémoire (la nouveauté 11.0)

Voici le troisième niveau, le plus fin, et celui qu’active WooCommerce 11.0.

Sur une seule page produit, WooCommerce peut appeler wc_get_product() des dizaines de fois pour le même produit : une fois pour le titre, une fois pour le prix, une fois pour le stock, une fois par variation, une fois par produit lié… À chaque appel, l’objet produit est reconstruit. C’est du travail redondant, dans une seule et même requête.

Le « product object caching » intercepte ces appels et sert l’objet depuis un cache mémoire à portée de requête (request-scoped). Caractéristiques officielles :

Le cache est non persistant : il est vidé à la fin de chaque requête. Rien à voir avec Redis, qui survit entre les requêtes.
Les appels répétés pour un même produit renvoient des clones, pas des références — impossible de partager par accident un état modifié entre deux portions de code.
Aucune gestion manuelle n’est requise.

Les gains annoncés par WooCommerce (mesurés dès la phase expérimentale en 10.5) : les produits variables se chargent ~9-12 % plus vite sur les pages produit, et les produits groupés (bundles) sont traités 6-12 % plus vite au checkout (source : developer.woocommerce.com).

Ce niveau est complémentaire des deux autres : il ne remplace ni le page cache, ni Redis. Il élimine simplement le gaspillage à l’intérieur d’une requête.

Ce que WooCommerce 11.0 change exactement

La fonctionnalité a suivi un parcours classique : introduite en expérimental en 10.5, passée de « incompatible » à « compatible » par défaut en 10.6 (aucun souci détecté dans l’écosystème d’extensions), et désormais activée automatiquement en 11.0 — mais seulement à l’installation d’une nouvelle boutique. C’est le même schéma que celui suivi par HPOS.

Le point important : les boutiques existantes ne sont pas touchées par la mise à jour.

Scénario	Ce qui se passe	Action nécessaire
Nouvelle install en 11.0+	Fonctionnalité activée automatiquement	Aucune
Boutique existante, fonctionnalité était OFF	Reste OFF après l’upgrade	L’activer manuellement si souhaité
Boutique existante, fonctionnalité était ON	Reste ON après l’upgrade	Aucune

Autrement dit : si votre boutique tourne depuis un moment et que vous mettez simplement à jour vers 11.0, vous ne profitez pas automatiquement de cette optimisation gratuite. Pour l’activer : WooCommerce → Réglages → Avancé → Fonctionnalités, puis cochez « Cache Product Objects » (Cache des objets produit).

Le piège : quand NE PAS l’activer sans tester

Pour la grande majorité des boutiques, activer ce cache est sans risque et tout bénéfice. Mais il existe un cas à surveiller.

Les extensions qui font des requêtes SQL directes sur les données produit, sans passer par les hooks meta standard de WordPress, peuvent renvoyer des données périmées : leurs requêtes contournent les hooks qui déclenchent l’invalidation du cache. Les extensions qui récupèrent les produits exclusivement via wc_get_product() et les API WooCommerce standard ne sont pas concernées.

Le cas typique : un plugin de prix dynamiques (tarifs indexés sur le cours d’une matière première, prix recalculés en temps réel, B2B avec tarifs par client…). Si le prix doit être réévalué à chaque appel et qu’il se retrouve figé en cache le temps de la requête, vous affichez un mauvais prix. Sur ce type de boutique, testez en préproduction avant d’activer — et gardez la possibilité de désactiver la fonctionnalité.

À terme, WooCommerce prévoit d’activer cette fonctionnalité sur toutes les boutiques, y compris existantes, en fonction des données d’adoption. Pas de calendrier annoncé, mais autant prendre les devants : vérifier dès maintenant si votre site est compatible vous évitera une surprise le jour où l’activation deviendra automatique pour tout le monde.

Bonus : quels caches sont réellement actifs chez vous ?

Beaucoup de boutiquaires croient avoir « le cache » sans savoir lesquels des trois niveaux tournent vraiment. Voici comment vérifier en deux commandes WP-CLI.

Le cache d’objets persistant (niveau 2) est-il actif ?

wp eval 'echo wp_using_ext_object_cache()
  ? "Object cache persistant : ACTIF\n"
  : "Object cache persistant : INACTIF (pas de Redis/Memcached)\n";'

Si la réponse est INACTIF et que votre boutique a du trafic, c’est souvent le levier de performance le plus rentable à mettre en place.

Le cache produit de WooCommerce (niveau 3) est-il activé ?

wp option get woocommerce_feature_product_instance_caching_enabled

La valeur yes signifie qu’il est actif, no (ou option absente) qu’il ne l’est pas. Sans WP-CLI, l’information est dans WooCommerce → Réglages → Avancé → Fonctionnalités. Et pour vérifier le cache persistant sans ligne de commande, regardez Outils → Santé du site : WordPress y signale si un cache d’objets persistant est en place.

Vous ne savez pas quelles couches de cache tournent sur votre boutique, ni si une extension risque de servir des prix périmés ? Demandez un audit gratuit — l’architecture de cache fait partie des premières choses que j’analyse dans une optimisation WooCommerce.