Le cache de page est le levier n°1 d'une boutique anonyme : home, page catégorie, page produit. Le tunnel (panier, page de commande, compte…) est l'inverse : il est personnel, il change à chaque clic, il parle à la caisse. Mélanger les deux, c'est le classique que je récupère après une « optimisation » du week-end. Cet article dit ce qu'il ne faut surtout pas cacher sur WooCommerce et PrestaShop, comment le vérifier, et comment rester rapide sans servir le mauvais prix.
🧊 Deux métiers : page publique vs caisse
Une page publique se ressemble pour tout le monde (ou presque). On peut la mettre en cache de page 5 à 30 minutes, parfois plus. Une page de caisse dépend de votre panier, vos règles, votre session. La cacher, c'est soit servir un panier vide à quelqu'un qui vient d'ajouter, soit servir le panier d'un autre.
WooCommerce pose des cookies (`woocommerce_items_in_cart`, session). PrestaShop a son cookie et son contexte (groupe, devise, boutique). Un plugin de cache qui « ignore les cookies » pour gagner 20 points Lighthouse ignore aussi la caisse.
🛒 Ce qu'on exclut toujours du cache (liste courte)
Panier, tunnel de vente, confirmation, mon compte, reset mot de passe, preview admin, endpoints AJAX du tunnel, pages de paiement. Sur Woo : `/cart/`, `/checkout/`, `/my-account/`, parfois `?add-to-cart=`. Sur Presta : `controller=cart`, `order`, `identity`, `discount`.
Les fragments (mini-panier dans le header) sont le piège. La page est « publique » mais le header affiche 3 articles. Si le cache fige ce header, tout le monde voit 3 articles. Soit on ne cache pas la page, soit on charge le mini-panier en JS après, soit on a un ESI / un edge intelligent. Les trois se documentent. Le « on verra » se paie en tickets.
- Panier, tunnel de vente, compte, confirmation
- AJAX / API du tunnel
- Pages avec cookie de session boutique
- Aperçus et URLs d'admin
📦 Ce qu'on cache (et comment)
Home, CMS, page catégorie, page produit anonyme : oui, avec une purge à la mise à jour stock / prix. Les prix spécifiques B2B cassent ce modèle : on segmente le cache par groupe, ou on ne cache pas la page produit, ou on calcule le prix en JS authentifié. Pas les trois à la fois.
Un object cache (Redis) n'est pas un cache de page. Il accélère l'admin et les requêtes. Il ne remplace pas l'exclusion du tunnel. Voir l'article Redis / object cache.
🔎 Comment vérifier en 20 minutes
Deux navigateurs, deux sessions. Ajouter un produit dans A. Recharger la home et une page produit dans B. Le mini-panier de B doit rester vide. Vider le cache, recommencer. Regarder les en-têtes `Cache-Control`, `X-Cache`, les cookies posés trop tôt (un cookie sur toutes les pages = souvent plus aucun cache de page).
En préprod, pas en soldes. Puis en prod sur un SKU test. Cache et tunnel se vérifient comme un paiement sandbox : c'est de la caisse.
Un Lighthouse vert avec un panier fantôme n'est pas une boutique rapide. C'est une boutique qui ment.
🛠️ Plugins et modules qui mentent
Les plugins « cache tout, ignore cookies », les minify qui cassent le JS du tunnel de vente, les CDN qui mettent en cache des réponses contenant `Set-Cookie`. On les nomme dans le runbook. On n'empile pas un second cache pour « corriger » le premier.
Un seul cache de page, des exclusions écrites, une purge connue. C'est de la TMA. Ce n'est pas une option du thème.
✅ Après une campagne ou une maj
On revérifie les exclusions : un plugin de tunnel de vente one-page ajoute souvent une URL. Une maj Woo renomme parfois un endpoint. Voir pourquoi Woo casse après une maj, et l'audit avant campagne.
Si vous voulez que je m'en charge : accès cache + une commande test. En une heure je sais si le tunnel est vivant ou embaumé.
✅ La liste de contrôle après un réglage de cache
Avant de toucher au cache, on note ce qui doit rester vivant : panier, compte, paiement, prix par client. Après, on rejoue ces mêmes parcours, pas un score de vitesse.
Sauvegarde restaurable, accès à votre nom, puis le réglage. Ensuite 24 à 72 h d'observation : abandon de panier, erreurs de paiement, logs. Sans cette phase de suivi, on a changé un réglage sans savoir s'il tient.
- Parcours d'achat noté avant le réglage
- Test sur une copie, pas en pleine campagne
- Une règle de cache modifiée à la fois
- Vérification humaine puis 24 h de suivi calme
📌 Ce que je refuse sur ce sujet
Je refuse les plugins de cache « magiques » qui promettent tout sans lister les exclusions. Je refuse d'ajouter une couche de plus pour masquer un panier mal conçu. Je refuse les réglages en production un jour de soldes.
Je refuse aussi le silence : si le vrai sujet est l'hébergement, le thème ou une refonte du tunnel, je vous le dis. Ce texte n'est pas un prétexte pour vendre un module de cache.
🧭 Questions fréquentes
Faut-il agir tout de suite ? Oui si des clients voient déjà le panier d'un autre, un mini-panier figé ou un paiement qui boucle. Sinon, planifiez la revue des exclusions de cache avant la prochaine opération commerciale, pas après.
Peut-on régler le cache directement en production ? C'est mal vu : une règle d'exclusion fausse se découvre sur de vrais paniers. Je teste sur une copie de la boutique avec un faux produit, puis j'applique. Le même réflexe vaut pour WooCommerce et PrestaShop.
Combien de temps ? Une à deux demi-journées pour lister les pages sensibles, poser les exclusions et rejouer un achat complet. Un devis « cache réglé en une heure » ignore les cookies, le mini-panier et le paiement.
