Un cache HTML partagé peut accélérer le catalogue, mais il ne doit pas servir le panier, le compte ou le paiement d’un visiteur à un autre. Les bonnes exclusions cache WooCommerce protègent l’état client à toutes les couches : extension WordPress, serveur, proxy et CDN.
Configurer une seule case ne suffit pas si une couche amont continue de stocker la réponse. La preuve repose sur des scénarios croisés avec des navigateurs et des sessions distincts.
Sommaire
La réponse courte
Identifiez les pages réellement attribuées à panier, paiement et compte, y compris les endpoints et variantes de langue. Excluez-les du cache de page partagé. Respectez les cookies et sessions WooCommerce, et évitez de mettre en cache une réponse privée sous une clé publique.
Testez avec deux navigateurs séparés : panier vide et panier rempli, visiteur et client, devises ou langues si utilisées. Vérifiez les en-têtes de cache à chaque couche et répétez après connexion, ajout, coupon et paiement en mode test.
WooCommerce indique dans sa documentation développeur que Cart, Checkout et My Account doivent rester dynamiques.
Principes qui restent valables
Les pages de panier, compte et paiement affichent des données propres à la session. Elles peuvent être construites avec shortcodes classiques ou blocs actuels ; l’exigence de confidentialité ne change pas.
Les caches gérés et CDN proposent davantage de règles automatiques, mais l’intégration dépend de la configuration. Un nouveau sous-domaine, une langue ou un checkout personnalisé peut sortir du périmètre attendu.
Cartographier toutes les couches
Listez cache navigateur, service worker, extension de page, cache serveur, proxy inverse, CDN, cache objet et cache de base. Chacun stocke un objet différent et possède sa propre clé et invalidation.
Le cache objet peut servir des données applicatives sans mettre en cache toute la page. Le CDN peut stocker l’HTML avant même que WordPress voie la requête. Ne confondez pas leurs réglages.
Documentez la priorité et la manière d’observer HIT, MISS, BYPASS ou équivalent sans révéler les fournisseurs réels.
Vérifier les pages attribuées
Dans les réglages WooCommerce, confirmez les pages Cart et Checkout, ainsi que My Account et les conditions. WooCommerce exige des pages attribuées pour que l’achat fonctionne.
Ne supposez pas que l’URL est toujours /cart/ ou /checkout/. Elle peut être traduite, personnalisée ou différente par boutique. Construisez les exclusions à partir de la configuration et des endpoints réels.
La documentation des réglages avancés WooCommerce décrit ces attributions.
Comprendre la clé de cache
Une clé détermine quelles requêtes partagent une réponse. Elle peut inclure hôte, chemin, paramètres, langue, appareil, cookies ou en-têtes. Omettre une dimension qui modifie le contenu crée une collision.
Ajouter chaque cookie à la clé peut au contraire fragmenter le cache jusqu’à le rendre inutile. Pour les pages privées, préférez souvent un bypass complet ; pour le catalogue variable, définissez seulement les dimensions nécessaires.
Testez la clé réelle du cache amont, pas seulement celle de WordPress.
Exclure panier, paiement et compte
Ajoutez les pages et leurs sous-chemins aux règles de non-cache HTML. Incluez confirmation de commande, ajout de moyen de paiement, modification d’adresse et endpoints du compte selon le site.
Vérifiez les variantes avec ou sans slash, paramètres légitimes, langue et domaine. Une règle exacte peut manquer une URL secondaire ; une règle trop large peut désactiver le cache du catalogue.
Utilisez la documentation de la couche concernée et conservez un test après chaque mise à jour.
Respecter les cookies de session
WooCommerce utilise des cookies pour suivre panier et session. Une couche compatible peut contourner le cache lorsqu’un cookie pertinent est présent. Confirmez le comportement, car certaines couches ne voient pas ou ne respectent pas ces règles.
Ne publiez pas les valeurs de cookies. Dans un diagnostic, notez seulement présence, absence et décision de cache.
Après un panier vidé, testez aussi la suppression ou la conservation de la session et la réapparition d’une réponse publique.
Traiter le mini-panier
Le mini-panier peut être rendu côté serveur, rafraîchi par JavaScript ou fourni par un bloc. Une page catalogue mise en cache doit afficher un état correct après ajout et navigation.
Testez ajout, suppression, quantité, navigation arrière et nouvel onglet. Vérifiez que le fragment dynamique ne devient pas une fuite d’un utilisateur à l’autre.
N’ajoutez pas plusieurs systèmes de fragments sans mesurer leur effet sur requêtes et fiabilité.
Gérer clients connectés
Les utilisateurs connectés reçoivent souvent un bypass global du cache de page. Vérifiez-le avec un compte client, un éditeur et un administrateur. Un CDN mal configuré peut ignorer ce statut.
Le catalogue connecté peut afficher prix, remise ou contenu différents. Si vous souhaitez le mettre en cache, construisez une stratégie explicite par segment et évaluez le risque.
La simplicité et la confidentialité priment sur quelques HIT supplémentaires.
Traiter devises, langues et taxes
Une boutique multi-devise ou multilingue varie prix, textes et parfois URLs. La localisation fiscale peut dépendre d’adresse, géolocalisation ou session. La clé ou le bypass doit suivre la logique réelle.
Testez deux devises et deux langues dans des navigateurs séparés. Vérifiez catalogue, panier, paiement et e-mail de test. Une valeur correcte au paiement ne compense pas un prix public trompeur.
Évitez les règles génériques copiées d’une boutique à une autre.
Contrôler les requêtes d’ajout au panier
Les endpoints d’ajout et d’API modifient l’état ; ils ne doivent pas être servis depuis une réponse cache partagée. Vérifiez méthode HTTP, paramètres, cookies et en-têtes de réponse.
Une requête GET qui modifie le panier peut être traitée de façon spéciale par une couche amont. Testez-la et évitez de précharger ou crawler des URLs d’action.
Contrôlez aussi les liens de retrait et coupons.
Purger sans casser les sessions
La mise à jour d’un produit doit invalider les pages publiques concernées. Elle ne nécessite pas de supprimer arbitrairement toutes les sessions clients. Distinguez purge HTML, fragments, transients et objets.
WooCommerce fournit des outils système pour certaines tâches. Lisez l’effet de chaque action avant de l’exécuter ; certaines sont destructives.
Planifiez la purge et surveillez la reconstruction pendant une campagne.
Tester avec deux navigateurs
Utilisez deux profils réellement séparés, pas deux onglets partageant les cookies. Dans A, ouvrez le catalogue sans panier. Dans B, ajoutez un produit, changez quantité et connectez-vous si prévu.
Rechargez A : il doit rester anonyme et vide. Rechargez B : son état doit persister. Alternez les requêtes pour tenter de provoquer une collision.
Vérifiez visuellement et par en-têtes de cache. Répétez après purge et expiration.
Tester le paiement en mode sûr
Utilisez une passerelle de test et des données fictives. Vérifiez adresse, livraison, taxes, coupon, moyen de paiement, validation, commande et confirmation.
Rechargez la page, utilisez le bouton retour et simulez une erreur. Assurez-vous qu’aucune réponse cache ne réutilise un jeton ou une information de session.
Ne testez jamais avec une carte réelle ni ne publiez les journaux de paiement.
Inspecter les en-têtes
Regardez Cache-Control, Age, Vary et les en-têtes propres à la couche. Une page privée devrait indiquer un comportement cohérent avec le bypass. Un en-tête WordPress ne garantit pas que le CDN l’a respecté.
Comparez la première et la seconde requête, avec et sans cookie. Relevez la couche qui répond et la clé supposée.
Masquez cookies, URL de commande et identifiants dans les captures.
Tester une page de confirmation
La confirmation peut contenir identifiant, résumé et instructions. Elle doit rester privée et liée à la session ou au mécanisme de sécurité prévu.
Ouvrez l’URL depuis une session distincte et vérifiez qu’elle ne révèle rien. Testez après expiration et déconnexion. Contrôlez que la couche amont n’a pas stocké le document.
Traitez toute fuite comme un incident, pas comme une anomalie visuelle.
Surveiller après déploiement
Contrôlez taux HIT du catalogue, bypass des pages privées, erreurs panier, abandons, commandes et plaintes de session. Une chute soudaine de HIT peut indiquer une règle trop large ; une hausse d’erreurs peut révéler une règle trop étroite.
Conservez des tests synthétiques séparés : catalogue public, panier propre, connexion et paiement de test selon la politique.
Rejouez la matrice après mise à jour de WooCommerce, thème, cache ou CDN.
Ordre de configuration recommandé
- Inventorier les couches de cache.
- Confirmer pages et endpoints WooCommerce.
- Définir ce qui est public et privé.
- Exclure panier, compte, paiement et confirmation.
- Gérer session, connexion, langue et devise.
- Configurer l’invalidation du catalogue.
- Tester deux navigateurs réellement séparés.
- Tester une commande en mode sûr.
- Inspecter les en-têtes à chaque couche.
- Surveiller et rejouer après chaque changement.
Les erreurs à éviter
- Copier seulement
/cart/et oublier l’URL configurée. - Exclure dans l’extension mais pas dans le CDN.
- Ajouter tous les cookies à la clé sans stratégie.
- Tester deux onglets du même profil.
- Mettre en cache la confirmation de commande.
- Purger toutes les sessions pour mettre à jour un produit.
- Tester avec un moyen de paiement réel.
- Publier cookies, URLs privées ou en-têtes sensibles.
Checklist exclusions cache WooCommerce
- [ ] Toutes les couches et clés sont cartographiées.
- [ ] Les pages attribuées sont vérifiées dans WooCommerce.
- [ ] Panier, paiement, compte et endpoints privés contournent l’HTML partagé.
- [ ] Les cookies de session produisent le comportement attendu.
- [ ] Connexion, langues, devises et taxes sont testées si utilisées.
- [ ] Mini-panier et ajout au panier restent cohérents.
- [ ] Deux navigateurs prouvent l’absence de fuite.
- [ ] Le paiement est validé en mode test.
- [ ] Les en-têtes confirment chaque couche.
- [ ] Une surveillance détecte régression et sur-exclusion.
Conclusion
Les bonnes exclusions cache WooCommerce séparent l’HTML public et réutilisable de chaque réponse liée à une session, un compte ou une commande. Elles doivent s’appliquer jusqu’à la couche la plus proche du visiteur.
La preuve vient d’un test croisé, pas d’un réglage affiché. Pour compléter cette configuration par une approche de campagne mesurée, consultez préparer WooCommerce au trafic.
Pour poursuivre cette série éditoriale, consultez également mesurer WordPress avec les données terrain et laboratoire.