Comment accélérer une boutique WooCommerce sans casser le panier

Une boutique lente perd des ventes deux fois : une fois sur la fiche produit, quand le visiteur part avant qu'elle ne se charge, et une fois au moment de commander, quand un panier cassé ou un champ de paiement figé le fait fuir. La plupart des conseils de performance traitent une boutique comme un blog. C'est exactement comme ça que des paniers se vident, que des prix deviennent faux et que des boutons de paiement cessent de répondre.

Ce guide est la carte. Il montre ce qui peut être optimisé sur une boutique, ce qui ne doit jamais l'être, et renvoie vers le guide détaillé de chaque problème.

Une boutique, ce sont deux sites en un

Le catalogue, c'est la page d'accueil, les pages catégories et les fiches produits. Chaque visiteur voit la même chose, donc ces pages peuvent être mises en cache, allégées et différées comme n'importe quelle autre page.

La transaction, c'est le panier, la page de commande et le compte client. Chaque visiteur y voit son propre contenu : ses articles, son adresse, ses commandes. Ces pages ne doivent jamais être servies depuis un cache, et les optimisations qui reposent sur un instantané de la page ne s'y appliquent pas.

Et entre les deux, il existe un troisième état : un visiteur qui parcourt le catalogue avec des articles dans son panier. La page semble publique, mais l'en-tête affiche son panier. WooCommerce marque ce visiteur avec des cookies comme woocommerce_items_in_cart et wp_woocommerce_session_, et un cache de page correct s'efface devant lui.

Un cache de page qui respecte le panier

Le cache de page est le plus gros gain sur une boutique, et le réglage le plus dangereux. Trois règles :

• Excluez les pages transactionnelles : panier, page de commande et toutes les pages du compte. Servir une page de commande en cache peut montrer à un client les informations d'un autre.
• Contournez le cache pour les visiteurs qui ont un panier ou une session : sinon l'en-tête affiche un panier vide à quelqu'un qui vient d'ajouter un produit, ou le compteur de panier d'un autre visiteur.
• Surveillez les paramètres d'URL : les liens add-to-cart, les paramètres de suivi comme utm_source ou gclid, et les filtres. Chaque URL distincte peut devenir un cache miss.

Le piège de la géolocalisation. L'option « Géolocaliser (avec prise en charge de la mise en cache des pages) » de WooCommerce ajoute un paramètre v aux URL pour que chaque pays ait sa propre version en cache. Si vous n'avez pas besoin de prix ou de taxes par pays, ce mode fragmente votre cache pour rien. Si vous en avez besoin, sachez que chaque page du catalogue existe désormais en autant de versions qu'il y a de localisations.

Des cookies posés pour rien. Un nouveau visiteur au panier vide ne devrait recevoir aucun cookie sur une page du catalogue. Un seul en-tête Set-Cookie suffit pour que la plupart des CDN, Cloudflare compris, refusent de mettre la page en cache, et pour que beaucoup de caches de page s'effacent. Les coupables habituels : une extension qui ouvre une session WooCommerce pour chaque visiteur (listes de souhaits, sélecteurs de devise, produits récemment consultés), ou un cookie de compteur de panier écrit même quand le panier est vide. Vérifiez-le comme un nouveau visiteur :

# Une page du catalogue, en nouveau visiteur au panier vide : aucune ligne ne doit revenir.
curl -s -o /dev/null -D - https://your-store.com/product/any-product/ | grep -i "set-cookie"

Si un cookie revient, trouvez l'extension qui le pose et faites-la attendre que le visiteur ajoute réellement quelque chose au panier.

Cart fragments : la requête sur chaque page

Le mini-panier de l'en-tête est tenu à jour par une requête AJAX, wc-ajax=get_refreshed_fragments, envoyée par wc-cart-fragments.js. Elle n'est jamais mise en cache, donc elle sollicite PHP et la base de données à chaque page vue où elle s'exécute.

Depuis WooCommerce 7.8, le script n'est plus chargé par défaut sur toutes les pages : seulement là où le widget classique de mini-panier en a besoin. Beaucoup de thèmes le chargent encore partout. Regardez l'onglet Network d'une page du catalogue : si la requête part sur des pages sans mini-panier, limitez le script aux pages qui en ont un. Ne le supprimez pas purement et simplement là où le mini-panier existe, sinon le compteur du panier cesse de se mettre à jour.

Quand des optimisations font disparaître le mini-panier ou l'empêchent de s'ouvrir, la cause et la correction sont détaillées dans notre guide sur le mini-panier WooCommerce.

Images produits : la partie la plus lourde du catalogue

• Les vignettes des grilles de catégorie : WooCommerce génère plusieurs tailles ; le navigateur ne choisit la bonne que si l'attribut sizes correspond à la grille. Un attribut sizes erroné fait télécharger aux téléphones les vignettes prévues pour ordinateur. Voir notre guide sur srcset et sizes.
• Une priorité mal placée : depuis WordPress 6.3, la première grande image d'une page reçoit fetchpriority="high". Sur une page d'accueil ou une page catégorie, c'est souvent la première vignette produit d'une grille bien en dessous de la ligne de flottaison, qui entre alors en concurrence avec la vraie image principale.
• L'image produit principale est généralement le Largest Contentful Paint d'une fiche produit. Elle ne doit pas être chargée en différé (lazy load), et elle peut changer entre mobile et ordinateur : notre guide sur l'image LCP selon l'appareil explique comment précharger la bonne.
• Les scripts de galerie, de zoom et de lightbox se chargent sur chaque fiche produit. Ce sont de bons candidats au report, tant que le bouton d'ajout au panier et les sélecteurs de variation continuent de fonctionner.

CSS et JavaScript sans casser la boutique

CSS allégé. Les outils de CSS utilisé (used CSS) rendent un seul état de la page. Sur une boutique, beaucoup d'éléments n'apparaissent qu'après une action : le mini-panier ouvert, une variation sélectionnée, une erreur de quantité, un champ de code promo. Leurs styles sont supprimés. La façon de trouver et de remettre les règles manquantes est expliquée dans notre guide sur les styles manquants. Et sur les pages panier, commande et compte, n'allégez pas du tout le CSS : l'instantané est pris déconnecté, avec un panier vide, et rate tout ce que voit le client.

JavaScript reporté. Ne reportez jamais l'ajout au panier, les scripts de variation, les scripts de commande ni les champs de paiement (formulaires de carte, boutons de paiement express) : un champ de paiement qui attend une première interaction, c'est une commande perdue. Reportez ce qui n'est pas nécessaire pour acheter : chat, widgets d'avis, pop-ups, pixels marketing. La méthode pour trouver ce qu'un report a cassé est dans notre guide sur le report du JavaScript, et un bandeau de consentement qui se charge tard est traité dans notre guide sur les bandeaux de consentement.

Décalages de mise en page. Les grilles de produits qui chargent leurs images sans dimensions, les badges promo et les étoiles d'avis qui apparaissent tard, et les barres d'ajout au panier fixes font tous bouger la page. Les causes et les corrections sont dans notre guide sur le CLS.

Les pages jamais mises en cache

Le panier et la page de commande sont toujours générés par PHP pour chaque visiteur, donc leur vitesse est la vitesse brute de votre serveur et de votre base de données. C'est là que l'hébergement, la version de PHP et la santé de la base se voient. Quelques points à vérifier :

• Les versions récentes de WooCommerce stockent les commandes dans des tables dédiées (High-Performance Order Storage), bien plus rapides que l'ancien stockage dans la table des articles sur les boutiques qui ont beaucoup de commandes.
• Les tables des actions planifiées et les sessions clients expirées peuvent devenir volumineuses sur une boutique très active ; vérifiez leur taille et leur nettoyage.
• Chaque extension qui se greffe sur le panier ou la page de commande s'exécute à chacune de ces requêtes : calculateurs de frais de port, ventes additionnelles, contrôles antifraude. Mesurez la page de commande avec et sans elles sur une copie de préproduction.

Mesurez la boutique, pas seulement la page d'accueil

• Testez une page catégorie et une fiche produit sur mobile, déconnecté, en nouveau visiteur.
• Testez à nouveau avec un article dans le panier : le cache doit s'effacer et la page doit rester rapide.
• Parcourez tout le tunnel d'achat après chaque modification : ajout au panier, changement de variation, application d'un code promo, arrivée à l'étape de paiement. Faites-le sur une copie de préproduction ou en mode test de votre passerelle de paiement : une commande de test sur une boutique en production est une vraie commande.
• Lisez les données de terrain, pas seulement le score de labo, comme expliqué dans notre guide sur les données de labo et de terrain, et changez un réglage à la fois, comme dans notre méthode pour optimiser sans casser.

Avec Mantys Core

En résumé

• Tracez d'abord la frontière : le catalogue est optimisé à fond, le panier, la commande et le compte ne sont jamais mis en cache ni allégés.
• Contournez le cache de page pour les visiteurs qui ont un panier, et surveillez les paramètres d'URL et la géolocalisation.
• Un panier vide ne doit recevoir aucun cookie : un seul Set-Cookie suffit pour empêcher le CDN de mettre la page en cache.
• Ne chargez les cart fragments que là où un mini-panier actif en a besoin.
• Dimensionnez correctement les images produits, gardez l'image principale en chargement immédiat, et corrigez la priorité des vignettes de grille.
• Ne reportez jamais les scripts d'ajout au panier, de variation, de commande ou de paiement ; reportez plutôt la couche marketing.
• Testez tout le tunnel d'achat, en préproduction ou en mode test, après chaque modification.