CDN pour WooCommerce : le guide de configuration

Une boutique WooCommerce fonctionne bien derrière un CDN quand l’edge sert les fichiers statiques et les pages de catalogue vues par les invités, tandis que tout ce qui est personnel ou transactionnel va directement à votre serveur : panier, commande, espace compte, visiteurs avec un panier actif, appels AJAX et API, et notifications de paiement. Bien régler ces conditions de contournement, garder les prix à jour avec des purges ciblées et tester une vraie commande représentent l’essentiel du travail de configuration. Pour le reste des performances de la boutique (extensions de cache, base de données, tâches de fond), consultez le guide pour accélérer WooCommerce.

Deux façons de placer un CDN devant une boutique

• CDN de ressources. Une extension réécrit les URL des images, du CSS et du JavaScript vers un nom d’hôte CDN, tandis que chaque page continue de venir de votre serveur. Le risque est faible, car aucune page n’est partagée entre clients, mais la partie la plus lente, la génération du HTML, reste inchangée.
• Proxy de site complet. Chaque requête passe par l’edge, HTML compris, si bien qu’une fiche produit en cache n’atteint jamais PHP ni la base de données. C’est là que se trouvent les gains les plus importants, et là que WooCommerce demande de la rigueur : l’edge est un cache partagé, et une seule règle erronée suffit pour que le client B voie le panier du client A.

La suite de ce guide porte sur la deuxième configuration. Si vous comparez encore les fournisseurs, le guide pour choisir un CDN pour WordPress présente les critères.

Ce que l’edge peut mettre en cache sans risque

« Pour les invités uniquement » est l’expression clé. La même URL de produit peut s’afficher différemment pour un client connecté ou pour quelqu’un qui a des articles dans son panier, et l’edge doit pouvoir distinguer ces requêtes.

Paramètres de requête

Les paramètres de suivi comme utm_source créent une entrée de cache distincte par variante, si bien qu’une campagne peut discrètement transformer des hits en miss. Les paramètres qui modifient le contenu, comme orderby ou les filtres de navigation à facettes, ont légitimement besoin de leurs propres entrées.

Ce qui doit toujours atteindre votre serveur

Les pages

Le guide WooCommerce sur la configuration des extensions de cache (en anglais) cite les pages Panier, Commande et Mon compte comme pages à exclure. Cela inclut tout ce qui se trouve en dessous, comme /checkout/order-received/ après le paiement et les pages de commandes et d’adresses sous /my-account/. Si vous avez renommé ces pages ou si votre boutique est multilingue, chaque slug et chaque version linguistique compte.

WooCommerce vous aide : sur les pages panier, commande et compte, il envoie des en-têtes Cache-Control qui interdisent la mise en cache. Un CDN qui respecte les en-têtes de l’origine ne les stockera pas. Vérifiez qu’aucune extension de cache ou de sécurité de votre site n’écrase ces en-têtes.

Les cookies

Les en-têtes ne couvrent que ces trois pages. Une fiche produit consultée par quelqu’un dont le panier est rempli a des en-têtes normaux, cachables, mais peut afficher son mini-panier, le contournement doit donc aussi dépendre des cookies. Ceux que WooCommerce liste sont :

• woocommerce_cart_hash et woocommerce_items_in_cart (posés dès qu’il y a quelque chose dans le panier)
• wp_woocommerce_session_* (la session client)
• woocommerce_recently_viewed et store_notice[notice id] (pertinents seulement si vous utilisez le widget des produits récemment consultés ou l’avis de boutique)

Ajoutez le cookie de connexion WordPress wordpress_logged_in_*, pour que les clients connectés et l’équipe reçoivent toujours des pages fraîches.

Les points d’accès

• les requêtes ?wc-ajax=, utilisées pour l’ajout au panier, l’application des codes promo et le rafraîchissement de la page de commande
• /wp-admin/, admin-ajax.php et wp-login.php
• les liens avec ?add-to-cart=
• la Store API (en anglais) sous /wp-json/wc/store/v1/, qui alimente le panier et la commande en blocs. Ses réponses reflètent la session du client en cours.
• l’API REST authentifiée sous /wp-json/wc/v3/, utilisée par les intégrations ERP, de gestion des stocks et de places de marché
• les notifications de paiement (voir plus bas)

Le mini-panier sur les pages en cache

Avec un thème classique, le compteur du mini-panier sur une page en cache est rempli après coup par le script cart fragments, qui appelle ?wc-ajax=get_refreshed_fragments et conserve le résultat dans le session storage du navigateur. Les thèmes en blocs chargent plutôt les données du panier par leurs propres requêtes, qui doivent elles aussi rester hors cache. La page peut être mise en cache précisément parce que la partie personnelle arrive par une requête séparée, non mise en cache. Si cette requête est mise en cache, tous les visiteurs voient le même compteur de panier. La question de savoir si vous avez vraiment besoin de cart fragments est traitée dans le guide pour accélérer WooCommerce.

Prix, devises et localisation

Un cache partagé ne fonctionne que si tout ce qui modifie une page est visible dans l’URL ou géré par un contournement. Les cookies et les adresses IP sont invisibles pour une clé de cache basée sur l’URL.

• Géolocalisation. Avec la simple option « Geolocate » comme emplacement client par défaut, les prix sont calculés côté serveur pour le pays du visiteur : derrière un cache partagé, c’est donc le pays du premier visiteur qui décide de ce que tout le monde voit. La documentation des réglages généraux de WooCommerce (en anglais) décrit l’option « Geolocate (with page caching support) » pour ce cas : elle géolocalise via AJAX et ajoute un paramètre ?v= aux URL. Chaque variante devient sa propre entrée de cache, attendez-vous donc à davantage de miss.
• Sélecteurs de devise. Beaucoup stockent la devise choisie dans un cookie. Si ce cookie ne déclenche pas de contournement, une page en cache affiche la devise dans laquelle elle a été générée la première fois. Préférez un sélecteur qui place la devise dans l’URL ou charge les prix côté client, et consultez sa documentation sur le cache.
• Prix propres à un client. Les prix de gros ou par rôle ne s’affichent généralement qu’aux utilisateurs connectés, qui contournent de toute façon le cache. Vérifiez que l’affichage des prix dépend bien de la connexion et non d’un cookie séparé.

Garder le stock et les prix à jour

Choisissez les durées de vie du HTML selon ce que vous coûte une page obsolète. Une page de contenu peut rester en cache pendant des heures ; une fiche produit dont le stock bouge vite doit expirer plus tôt ou être purgée à chaque modification.

• Modification d’un produit. Purgez l’URL du produit, les pages de catégories où il apparaît, la page boutique et la page d’accueil si le produit y est mis en avant.
• Imports et synchronisations ERP. Faites déclencher par la tâche d’import des purges d’URL via l’API de votre CDN, exactement pour les produits modifiés, au lieu d’attendre l’expiration des pages.
• Soldes programmées. Un prix soldé qui démarre à minuit n’atteint pas tout seul une page en cache. Programmez une purge pour ce moment-là.
• Changements sur tout le site. Après une mise à jour du thème ou une promotion sur toute la boutique, purgez tout, puis préchauffez vos principales catégories et vos meilleures ventes.

Que la purge se fasse automatiquement ou non dépend de votre configuration. Dans tous les cas, contrôlez les en-têtes de réponse par sondage après une modification.

Notifications de paiement et pare-feu

Les prestataires de paiement confirment les paiements en appelant votre serveur de boutique de serveur à serveur. L’API Payment Gateway de WooCommerce (en anglais) les traite via des URL wc-api, sous la forme /wc-api/<callback>/ ou /?wc-api=<callback>. Beaucoup d’extensions de paiement enregistrent aussi des routes de webhook sous /wp-json/. Si une notification échoue, les commandes restent au statut « Pending payment » (en attente de paiement) alors que le client a payé.

Ces requêtes ne doivent jamais être mises en cache et, tout aussi important, ne doivent jamais être bloquées :

• Règles par pays. Les serveurs d’un prestataire peuvent appeler depuis un pays que vous bloquez ou soumettez à un challenge sur tout le site.
• Challenges CAPTCHA. Un serveur ne peut pas résoudre un CAPTCHA, limitez donc les règles de challenge aux chemins utilisés par des humains.
• Limites de débit. Les webhooks peuvent arriver par rafales, par exemple après une série de remboursements. Dimensionnez les limites par IP en conséquence.
• Règles anti-bots. Les notifications de paiement et les intégrations ERP sont des clients automatisés. Vérifiez que les jeux de règles anti-bots ne les signalent pas.

Un plan de test pour la bascule

Exécutez-le en préproduction si possible, puis à nouveau juste après le changement de serveurs de noms (voir changer de serveurs de noms sans interruption).

1. Fiche produit en invité. Demandez-la deux fois. La deuxième réponse doit être un hit.
2. Panier et commande. En tant qu’invité, ils doivent afficher un bypass ou un miss, jamais un hit.
3. Panier actif. Ajoutez un produit et rechargez une fiche produit. Ce ne doit pas être un hit, et le mini-panier doit afficher votre article.
4. Deux navigateurs. Remplissez le panier dans le navigateur A. Le navigateur B doit toujours voir un panier vide.
5. Client connecté. Parcourez la boutique et l’espace compte. Rien ne doit venir du cache partagé.
6. Paiement de test. Passez une commande dans le mode sandbox ou test du prestataire et vérifiez que le statut de la commande quitte « Pending payment ». Cela prouve que la notification est bien passée.
7. Purge. Modifiez un prix, purgez l’URL et vérifiez que le nouveau prix apparaît.

Pour la vérification des en-têtes, envoyez la requête une fois sans cookie et une fois avec un cookie de panier :

curl -sI https://shop.example.com/product/example/ | grep -i -E "cache|age"
curl -sI -H "Cookie: woocommerce_items_in_cart=1" https://shop.example.com/product/example/ | grep -i cache

La deuxième requête ne doit pas revenir en hit. Une fois les tests fonctionnels réussis, comparez la vitesse avant et après avec un outil comme corewebvitals.page, qui affiche les données terrain d’utilisateurs réels et un test en laboratoire pour mobile et ordinateur.

Comment fast.site vous aide

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

Fast Edge Cache™ sert depuis l’edge les fiches produits, les catégories et les pages de contenu destinées aux invités, dans les régions incluses dans votre offre, et un HIT n’atteint jamais votre serveur. fast.site respecte les en-têtes Cache-Control de votre origine, et les réponses privées ou dynamiques comme le panier, la commande et les sessions connectées affichent fs-cache: BYPASS, ce qui vous permet de vérifier chaque étape du plan de test ci-dessus (voir vérifier le cache). Après des imports ou des changements de prix, vous purgez des URL individuelles ou tout le domaine dans le tableau de bord, avec un journal des purges, ou via l’API depuis vos propres scripts.

En edge, fast.site convertit aussi les images produits en WebP pour les navigateurs compatibles (AVIF selon votre offre) et filtre les inondations HTTP et les mauvais bots avant qu’ils n’atteignent votre boutique, avec des règles de pare-feu que vous maîtrisez. Les détails se trouvent sur la page WooCommerce.

Mesurez votre boutique avant et après sur vos propres pages, y compris une commande de test complète. Vous pouvez commencer avec un essai gratuit de 7 jours.

Questions fréquentes

Ai-je besoin d’un CDN pour WooCommerce ?

Pas toutes les boutiques. Si la plupart de vos clients sont proches de votre serveur et que les pages sont déjà rapides, un meilleur hébergement ou un CDN de ressources peut suffire. Un CDN de site complet est surtout rentable avec des visiteurs répartis sur plusieurs régions, des pics de trafic liés aux campagnes ou un serveur à la peine.

Un CDN peut-il mettre en cache les fiches produits WooCommerce ?

Oui, pour les invités. Les fiches produits, les catégories et la page boutique peuvent être mises en cache tant que les requêtes portant des cookies de panier ou de session WooCommerce et les utilisateurs connectés contournent le cache. Purgez les URL des produits quand le prix ou le stock change.

Un CDN va-t-il casser ma page de commande WooCommerce ?

Non, si le panier, la commande, les pages de compte, les requêtes wc-ajax, la Store API et les notifications de paiement contournent le cache et ne sont pas bloqués par les règles de pare-feu. Testez une commande complète avec un paiement en sandbox après chaque changement de configuration.

Faut-il garder mon extension de cache avec un CDN ?

Souvent, oui. Une extension de cache de pages accélère les requêtes qui atteignent votre serveur, comme les miss. Assurez-vous que l’extension et le CDN appliquent les mêmes exclusions, et purgez les deux après les modifications.