Accélérer WooCommerce sans casser le panier ni la commande

Vous pouvez rendre WooCommerce nettement plus rapide en mettant en cache les pages que tous les clients voient de la même façon, comme les fiches produits, les catégories et les pages de contenu, tandis que le panier, la commande et le compte client restent entièrement dynamiques. La plupart des paniers cassés après un projet d’optimisation viennent d’un non-respect de cette séparation. Ce guide montre quelles pages vont de quel côté, comment le vérifier et ce qui ralentit encore une boutique une fois le cache en place.

Pourquoi WooCommerce est plus lent que WordPress seul

WooCommerce tourne sur WordPress, donc tout ce qui ralentit WordPress s’applique aussi ici : hébergement, extensions, thème et images. Si vous n’avez pas encore vérifié ces bases, commencez par comprendre pourquoi un site WordPress est lent.

Une boutique ajoute ensuite sa propre charge :

• Plus de données par page. Les fiches produits interrogent les prix, les variations, le stock, les classes de taxe, les avis et les produits associés.
• Sessions et cookies. Dès qu’un visiteur ajoute un produit au panier, WooCommerce ouvre une session et pose des cookies. À partir de là, les requêtes de ce visiteur sont personnelles.
• Requêtes AJAX. Les boutons d’ajout au panier, les mini-paniers et les mises à jour de la page de commande appellent le serveur via les points d’accès wc-ajax.
• Tâches en arrière-plan. E-mails de commande, synchronisations de stock, webhooks et actions planifiées tournent en parallèle du trafic normal.
• Extensions. Passerelles de paiement, calculateurs de livraison, filtres produits et outils marketing ajoutent chacun des scripts et des requêtes.

Le temps de réponse d’une boutique sans cache est donc plus élevé que celui d’un blog, ce qui rend le cache à la fois plus précieux et plus délicat.

Ce que vous pouvez mettre en cache, et ce que vous ne pouvez pas

La règle est simple : si la page est identique pour tous les visiteurs anonymes, mettez-la en cache. Si elle dépend de la personne qui la consulte, ne le faites pas.

WooCommerce documente les pages et les cookies à exclure dans son guide sur la configuration des extensions de cache (en anglais). Les cookies les plus importants sont woocommerce_items_in_cart, woocommerce_cart_hash et wp_woocommerce_session_*, auxquels s’ajoutent les cookies de connexion de WordPress.

Contournement par cookie

Les règles d’URL ne suffisent pas. Dès qu’un visiteur a quelque chose dans son panier, même une fiche produit peut afficher un mini-panier avec ses articles. Une bonne configuration de cache contourne toute requête qui porte un cookie de session ou de panier WooCommerce, afin qu’un client au panier rempli ne voie jamais la page de quelqu’un d’autre.

Testez le panier et la commande après chaque changement

Dans une boutique, une modification de performance exige un test fonctionnel, pas seulement un test de vitesse. Après avoir activé ou modifié le cache, parcourez tout le tunnel d’achat dans une fenêtre de navigation privée :

1. Ouvrez une fiche produit en tant que visiteur anonyme.
2. Ajoutez le produit au panier et vérifiez que le mini-panier se met à jour.
3. Ouvrez le panier, modifiez la quantité, appliquez un code promo.
4. Passez à la commande, changez le pays de livraison et regardez les totaux se mettre à jour.
5. Passez une commande de test avec un moyen de paiement en mode sandbox.
6. Connectez-vous en tant que client et ouvrez l’espace compte.

Vérifiez ensuite les en-têtes de réponse des pages panier et commande. Ils doivent indiquer un contournement (bypass) ou un miss, jamais un hit :

curl -sI https://shop.example.com/checkout/ | grep -i -E "cache|set-cookie"

Gardez les pages en cache à jour

Mettre les fiches produits en cache soulève une question légitime : que se passe-t-il quand le prix ou le stock change ?

• Purger à la mise à jour. Quand vous modifiez un produit, purgez son URL et les pages de catégories où il apparaît. Beaucoup de configurations de cache le font automatiquement via une extension ou un appel d’API.
• Durées courtes pour les pages volatiles. Si le stock change en permanence, donnez aux fiches produits une durée de cache plus courte plutôt que de renoncer au cache.
• Préchauffer les pages importantes. Après une purge, le premier visiteur provoque un miss. Préchauffer les meilleurs produits et catégories les garde rapides.
• Soldes et imports. Avant le début des soldes ou après un import massif de prix, purgez délibérément les pages concernées.

Géolocalisation et devises

Si votre boutique affiche les prix selon le pays du visiteur, les pages en cache peuvent montrer la mauvaise taxe ou la mauvaise devise. Pour l’emplacement client par défaut, WooCommerce propose l’option « Geolocate (with page caching support) » (libellé de l’interface anglaise), qui ajoute un paramètre de requête afin que chaque emplacement ait sa propre copie en cache. Les extensions de changement de devise demandent un traitement similaire. Vérifiez dans leur documentation qu’elles prennent en charge le cache avant de compter sur elles.

Accélérez les parties dynamiques

Le panier et la commande ne seront jamais mis en cache, leur vitesse brute dépend donc du serveur et du code.

Cart fragments

Les thèmes classiques chargent souvent le script wc-cart-fragments, qui appelle le serveur au chargement de la page pour rafraîchir le mini-panier. Sur une boutique très fréquentée, cela ajoute une requête non mise en cache à chaque page vue servie depuis le cache. Vérifiez si votre thème en a réellement besoin. Si vous n’affichez pas de mini-panier dans l’en-tête, vous pouvez peut-être vous en passer, et de nombreuses extensions de performance proposent un réglage pour cela.

La page de commande

• Supprimez les champs et les extensions de commande inutiles : chaque extension de livraison ou de paiement ajoute des scripts et des appels serveur.
• Chargez les scripts de paiement uniquement sur la page de commande, pas sur tout le site.
• Limitez le nombre de mises à jour AJAX sur la page de commande. Chaque changement d’adresse ou de mode de livraison recalcule les totaux côté serveur.

La réactivité de la page de commande correspond exactement à ce que mesure l’INP (en anglais) : la rapidité avec laquelle la page réagit quand un client clique ou saisit du texte.

Base de données et tâches en arrière-plan

• Activez le stockage des commandes haute performance (HPOS) si vos extensions le prennent en charge. Il place les commandes dans des tables dédiées au lieu de la table des publications.
• Surveillez Action Scheduler. Dans l’écran des actions planifiées (WooCommerce > Status > Scheduled Actions dans l’interface anglaise), une longue liste d’actions échouées ou en attente trahit souvent une extension qui se comporte mal.
• Ajoutez un cache d’objets persistant (Redis ou Memcached) pour que les requêtes répétées sur les produits, les options et les sessions soient servies depuis la mémoire.
• Remplacez WP-Cron par une vraie tâche cron serveur pour que le travail planifié ne s’exécute pas pendant la requête d’un client.

Pour une analyse détaillée des temps de réponse serveur, consultez le guide pour réduire le TTFB.

Images et scripts sur les fiches produits

Les galeries produits sont souvent la partie la plus lourde d’une boutique. Utilisez WebP ou AVIF, servez des tailles adaptées à la mise en page de la galerie et ne chargez pas en différé (lazy loading) l’image principale du produit, car c’est généralement votre élément LCP. Les scripts de zoom, de lightbox et de carrousel ne doivent se charger que sur les fiches produits, pas sur toutes les pages du site.

Passez aussi en revue vos scripts de suivi et de marketing. Chaque pixel, widget de chat et badge d’avis entre en concurrence avec le code de la boutique sur le thread principal.

Si vous gérez ou comparez d’autres solutions e-commerce, le guide de performance Shopware 6 traite la même séparation entre cache et contenu dynamique pour le cache HTTP de Shopware.

Comment fast.site vous aide

fast.site se place devant l’hébergement de votre boutique WooCommerce. Vous gardez votre hébergeur : vous ajoutez votre domaine dans le tableau de bord et vous faites pointer vos serveurs de noms vers fast.site. fast.site gère alors votre DNS, donc tous les enregistrements existants, y compris les enregistrements MX pour les e-mails de votre boutique, doivent figurer dans la zone DNS de fast.site.

Les fiches produits, les catégories et les pages de contenu destinées aux visiteurs anonymes peuvent être servies depuis l’edge par Fast Edge Cache™, dans les régions disponibles avec votre offre. Un HIT n’atteint jamais votre serveur d’origine, ce qui laisse plus de capacité pour le panier et la commande aux heures de pointe. Le panier, la commande, les pages de compte et les sessions doivent contourner le cache, et l’en-tête fs-cache affiche BYPASS pour elles, ce qui vous permet de vérifier chaque page avec le test de commande ci-dessus. Quand les prix ou le stock changent, vous purgez les URL dans le tableau de bord ou via l’API, et le préchauffage du cache garde les pages importantes prêtes.

fast.site peut aussi convertir à la volée les images produits en WebP (AVIF selon votre offre) et filtrer en edge les mauvais bots et les attaques par inondation HTTP avant qu’ils n’atteignent votre boutique. Consultez la page WooCommerce et l’article sur l’intégration WooCommerce pour les détails de configuration.

Mesurez votre boutique avant et après, en incluant un parcours de commande complet. Vous pouvez commencer avec un essai gratuit de 7 jours, sans carte bancaire.

Questions fréquentes

Peut-on mettre en cache les pages WooCommerce ?

Oui, pour les visiteurs anonymes, vous pouvez mettre en cache la page d’accueil, les pages de contenu, les archives de catégories et les fiches produits. Le panier, la commande, l’espace compte, les requêtes AJAX et tout visiteur portant un cookie de panier ou de session doivent contourner le cache.

Pourquoi ma page de commande WooCommerce est-elle lente ?

La page de commande n’est jamais mise en cache, elle révèle donc la vitesse brute de votre serveur et de vos extensions. Les causes fréquentes sont un hébergement lent, de nombreuses extensions de paiement et de livraison, des appels à des API externes pour les frais de port ou les taxes, et des recalculs fréquents pendant que le client remplit le formulaire.

Le cache casse-t-il le panier WooCommerce ?

Seulement s’il est mal configuré. Les problèmes apparaissent quand les pages panier ou commande, ou les requêtes avec des cookies de session WooCommerce, sont mises en cache. Excluez-les, puis testez le tunnel d’achat complet dans deux navigateurs en même temps.

Comment garder les prix et le stock à jour avec un cache ?

Purgez l’URL du produit et ses pages de catégories à chaque modification d’un produit, et purgez délibérément avant les soldes ou après les imports. Pour les boutiques dont le stock change en permanence, utilisez des durées de cache plus courtes sur les fiches produits.

Faut-il désactiver les cart fragments ?

Si votre thème n’affiche pas de mini-panier, la requête cart fragments est généralement une charge inutile. S’il en affiche un, gardez-la ou passez à une solution prise en charge par votre thème, et vérifiez que le compteur du panier se met toujours à jour après l’ajout d’un produit.