WooCommerce : les plugins de cache ne suffisent pas

L’illusion du cache

“Installez WP Rocket et votre site sera rapide.” C’est le conseil qu’on lit partout. Et c’est à moitié vrai. Mon service d’optimisation WooCommerce va bien au-delà du cache et traite les causes profondes de la lenteur.

Un plugin de page cache fait une chose simple : la première fois qu’une page est visitée, il sauvegarde le HTML généré et le sert directement aux visiteurs suivants, sans exécuter PHP ni interroger la base de données. Pour un blog ou un site vitrine, c’est magique. Pour un WooCommerce, c’est insuffisant.

Pourquoi ? Parce qu’une boutique WooCommerce est fondamentalement dynamique. Le panier change. Le checkout calcule des frais de port en temps réel. Le compte client affiche des données personnelles. Les stocks évoluent. Et tout ça ne peut pas être caché.

Ce que le cache ne couvre pas

Les pages dynamiques

Ces pages ne sont jamais servies depuis le cache (et ne doivent pas l’être) :

/cart/ - le panier
/checkout/ - le tunnel de commande
/my-account/ - l’espace client
Toute page avec un cookie de session WooCommerce

Si votre checkout met 3 secondes à charger, un plugin de cache n’y changera rien.

Les requêtes admin-ajax

C’est le point aveugle le plus courant. Comme l’explique la documentation de WP Engine (source : wpengine.com), les requêtes admin-ajax.php sont non cacheables - chaque requête est générée à neuf, bootstrap WordPress complet, chargement de WooCommerce, exécution PHP.

Le pire coupable : cart fragments. Ce script WooCommerce envoie une requête AJAX sur chaque page pour mettre à jour le mini-panier. Même sur votre page “Mentions légales”. Même pour les visiteurs avec un panier vide.

Selon la documentation officielle de WooCommerce (source : developer.woocommerce.com), le cart fragments est chargé “all the time, even when completely unnecessary”. À l’échelle, ça se traduit par des milliers de requêtes non cacheables par jour qui consomment des ressources serveur pour rien.

Les recherches et filtres produits

Quand un client filtre vos produits par taille, couleur ou prix, chaque combinaison génère une requête SQL. Plus votre catalogue est grand, plus ces requêtes sont lourdes. Un cache de page ne les accélère pas - il faudrait un Object Cache (Redis) pour mettre en mémoire les résultats de requêtes.

Le back-office

L’admin WordPress et le back-office WooCommerce ne sont jamais cachés. Si votre page “Commandes” met 5 secondes à charger avec 50 000 commandes, le cache côté visiteur n’y changera rien. C’est un problème de base de données - et la solution s’appelle HPOS.

Ce qui marche vraiment

Le cache est un accélérateur, pas une solution. Il faut d’abord résoudre les problèmes de fond, puis mettre le cache par-dessus.

1. Supprimer ce qui ne sert pas

Avant de cacher des pages lourdes, allégez-les. Identifiez les scripts et styles chargés inutilement sur chaque page. Un outil comme Perfmatters (source : perfmatters.io) avec son Script Manager permet de désactiver CSS et JS page par page.

Le thème est souvent le premier coupable. Comme le souligne Remkus de Vries (source : remkusdevries.com) : “WooCommerce itself already loads a lot of CSS and JavaScript, and if your theme also loads heavy fonts, jQuery plugins, and icon packs, you’ve just doubled the bloat.”

2. Nettoyer la base de données

Les options autoloadées se chargent à chaque requête - cachée ou non. Selon Kinsta (source : kinsta.com), garder les données autoloadées sous 800 Ko est la cible. Au-dessus, chaque requête commence par charger des Mo de données inutiles en mémoire.

3. Mettre en place le bon type de cache

Il n’y a pas un cache, il y en a trois, et ils ne font pas la même chose :

Object Cache (Redis) - Stocke les résultats de requêtes SQL en mémoire. C’est le plus impactant pour WooCommerce parce qu’il accélère les pages dynamiques : recherche produit, calcul de panier, back-office. Outil : Object Cache Pro + Redis.

Page Cache - Stocke le HTML complet pour les pages statiques. Efficace pour la homepage, les catégories, les pages de contenu. Inutile pour le panier et le checkout. Outil : WP Rocket, WP Super Cache, ou équivalent.

Edge Cache (CDN) - Distribue les pages cachées sur des serveurs dans le monde entier. Le visiteur reçoit la page depuis le serveur le plus proche. Outil : Cloudflare pour WooCommerce — Cloudflare APO (5$/mois, conçu pour WordPress).

4. Désactiver cart fragments

Le gain le plus rapide et le plus visible. Désactivez wc-cart-fragments.js sur toutes les pages sauf le panier et le checkout :

add_action( 'wp_enqueue_scripts', function() {
    if ( is_cart() || is_checkout() ) {
        return;
    }
    wp_dequeue_script( 'wc-cart-fragments' );
}, 999 );

D’ailleurs, depuis WooCommerce 7.8, le comportement par défaut a été amélioré : cart fragments n’est plus chargé automatiquement sur toutes les pages, seulement quand le widget panier est affiché. Mais beaucoup de thèmes forcent encore l’ancien comportement.

5. Migrer vers le checkout blocs

Le checkout blocs est plus léger que le legacy, se met à jour sans recharger la page, et supporte les paiements express natifs. C’est une optimisation directe de la partie du site que le cache ne peut pas aider.

Le piège du score Lighthouse

Un plugin de cache peut vous donner un score Lighthouse de 95/100 sur la homepage. Mais si votre checkout met 4 secondes à charger et que vos requêtes admin-ajax saturent le serveur, vos clients ne voient pas ce score - ils voient un site lent.

Lighthouse teste des pages statiques en conditions de labo. Vos clients naviguent des pages dynamiques en conditions réelles, avec un réseau mobile et un serveur sous charge.

C’est pour ça que je mesure toujours les Core Web Vitals terrain (données CrUX via PageSpeed Insights) en plus des audits Lighthouse. Les deux racontent une histoire différente.

En résumé

Un plugin de cache est nécessaire, mais c’est la dernière couche à mettre en place - pas la première. L’ordre logique :

Supprimer ce qui ne sert pas (scripts, styles, plugins inutiles)
Nettoyer la base de données (options autoloadées, transients)
Corriger les problèmes structurels (cart fragments, checkout legacy, HPOS)
Cacher ce qui peut l’être (Object Cache, Page Cache, Edge Cache)

Mettre le cache avant les étapes 1-3, c’est mettre un vernis sur un meuble bancal.

Votre plugin de cache ne suffit pas ? Demandez un audit gratuit - je regarde ce qui se passe en dessous.