Quelles pages ne faut-il jamais mettre en cache sur WooCommerce ?

Sur un site de contenu, activer un cache de pages est une opération sans risque qui divise le temps de réponse par dix. Sur une boutique, la même opération peut afficher le panier d'un visiteur à un autre, montrer un prix professionnel à un client particulier ou vider un panier en cours. La différence tient à une chose : une boutique WooCommerce sert des pages dont le contenu dépend de qui les demande, et un cache de pages, par construction, sert la même réponse à tout le monde. Savoir exactement quelles adresses relèvent de cette catégorie, et comment traiter les fragments personnalisés qui apparaissent dans des pages par ailleurs communes, règle la quasi totalité des incidents observés.

Pourquoi une boutique est un cas particulier

Le mécanisme du cache de pages est simple et c'est précisément cette simplicité qui pose problème dès que la personnalisation entre en jeu. Cette question s'inscrit dans la démarche générale que nous décrivons pour auditer la vitesse d'une boutique WooCommerce.

Ce que fait un cache de pages

Un cache de pages enregistre la réponse complète produite pour une adresse et la ressert telle quelle aux requêtes suivantes, sans exécuter le code du site. C'est ce qui explique le gain de performance considérable, et c'est aussi ce qui rend l'opération dangereuse : la réponse enregistrée contient tout ce qui figurait dans la page au moment de sa production, y compris ce qui concernait le visiteur qui l'a déclenchée. Aucun mécanisme ne distingue spontanément ce qui est commun de ce qui est personnel. C'est au configurateur de tracer cette frontière, et le cache appliquera ensuite fidèlement ce qu'on lui aura dit, y compris s'il s'agit d'une erreur.

La session, et ce qui la trahit

WooCommerce ouvre une session dès qu'un article est ajouté au panier, et cette session est portée par un témoin de connexion. Un cache correctement configuré doit détecter la présence de ces témoins et cesser de servir des réponses enregistrées à partir de ce moment. Les extensions de cache sérieuses le font nativement pour les témoins standard de la boutique, mais elles ignorent ceux ajoutés par des extensions tierces, ce qui explique les incidents survenant uniquement sur les sites équipés de modules de fidélité ou de tarification personnalisée. Le contrôle consiste à lister les témoins effectivement posés par le site puis à vérifier lesquels figurent dans la liste des témoins déclenchant le contournement du cache.

Le visiteur connecté

Les utilisateurs connectés ne doivent jamais recevoir de page issue du cache commun, puisque leur affichage diffère : prix négociés, historique, remises, barre d'administration. La plupart des configurations désactivent le cache pour tout utilisateur connecté, ce qui est la solution la plus sûre. Sur un site professionnel où l'essentiel du trafic est authentifié, cette règle annule pratiquement tout le bénéfice du cache, situation qui impose de recourir à des mécanismes différents, notamment la mise en cache par groupe d'utilisateurs. Cette approche suppose que le nombre de groupes reste faible, faute de quoi le cache se fragmente au point de ne presque jamais être utilisé.

Les pages à contenu partiellement variable

Le cas le plus courant n'est ni une page entièrement commune ni une page entièrement personnelle : c'est une fiche produit, identique pour tous, sur laquelle figure un compteur de panier et parfois un message de bienvenue. Mettre en cache la page complète fige ces éléments, ne pas la mettre en cache prive le site de l'essentiel du gain possible. La solution consiste à isoler ces fragments et à les charger séparément, méthode que toutes les extensions de cache prennent en charge sous une forme ou une autre. Bien mise en œuvre, elle permet de mettre en cache la quasi totalité des pages d'une boutique, ce qui est le résultat recherché.

Ce que le cache ne corrige pas

Un cache masque le temps de génération sans le réduire. Une fiche produit qui met deux secondes à être produite mettra toujours deux secondes lors de la première requête après une purge, et le robot d'exploration subira systématiquement ce délai puisqu'il visite des pages que personne n'a demandées récemment. C'est la raison pour laquelle la mesure du temps de génération réel, hors cache, reste indispensable, comme nous l'expliquons dans notre article sur la manière de mesurer le temps de réponse par gabarit de page.

Les pages à exclure sans discussion

Cette liste doit figurer dans la configuration de toute boutique, et sa vérification prend deux minutes. Une seule omission suffit à produire un incident visible par les clients.

Le panier

La page de panier affiche le contenu de la session en cours et n'a aucun sens partagée. Servie depuis un cache, elle montre soit un panier vide à un client qui vient d'ajouter un article, soit le panier de quelqu'un d'autre. Le second cas est rare mais spectaculaire, et il suffit d'une fois pour perdre la confiance d'un client. Cette page doit être exclue explicitement, sans se reposer sur la détection automatique, dont l'efficacité dépend de la configuration. L'exclusion doit porter sur le chemin de la page tel qu'il existe réellement, et non sur le chemin par défaut d'une installation neuve.

La validation de commande

La page de commande contient les données personnelles saisies, les totaux calculés et les jetons de sécurité protégeant l'envoi du formulaire. Un jeton mis en cache est un jeton périmé, ce qui produit des refus de soumission incompréhensibles pour le client, qui recommence sa saisie et abandonne. Ce symptôme précis, un formulaire de commande qui refuse d'être envoyé sans explication, est presque toujours le signe d'un cache mal réglé sur cette page. Il se manifeste souvent de façon intermittente, ce qui retarde le diagnostic et fait perdre des commandes pendant plusieurs jours.

Le compte client

L'ensemble des pages de l'espace client, historique de commandes, adresses, téléchargements, moyens de paiement, contient des données personnelles. Leur mise en cache constitue non seulement un défaut fonctionnel mais un incident de confidentialité, puisqu'un client peut se voir présenter les commandes d'un autre. Ces pages sont normalement protégées par la règle générale d'exclusion des utilisateurs connectés, mais cette règle doit être vérifiée et non supposée. Une seconde protection, consistant à interdire toute mise en cache des adresses de l'espace client par leur chemin, coûte une ligne et double la sécurité.

Les pages de remerciement et de suivi

La page affichée après un paiement contient le récapitulatif de la commande et sert souvent de déclencheur aux mesures de conversion. Mise en cache, elle affiche la commande précédente et fausse tous les suivis. Elle porte en outre une adresse comportant des paramètres propres à chaque commande, ce qui rend parfois la détection automatique inopérante lorsque le cache ignore les paramètres pour construire sa clé. L'exclusion par motif d'adresse plutôt que par identifiant de page est ici la seule méthode fiable.

Les points d'entrée programmatiques

Les adresses utilisées par les passerelles de paiement pour notifier le serveur, ainsi que celles des appels asynchrones du site, ne doivent jamais être mises en cache. Une notification de paiement servie depuis un cache renvoie une réponse enregistrée à la passerelle, qui peut interpréter cela comme un échec. Ces adresses sont généralement exclues par défaut, mais une configuration trop générale ou une réécriture personnalisée peut les faire entrer dans le périmètre du cache sans que rien ne le signale. Le symptôme est alors une commande payée qui reste en attente de paiement, situation particulièrement pénible à rattraper commande par commande.

La recherche interne

Les pages de résultats de recherche produisent une adresse distincte par requête, ce qui remplit le cache d'entrées servies une seule fois. Le bénéfice est nul et l'occupation disque peut devenir considérable sur un site visité par des robots qui explorent des combinaisons. L'exclusion de ces adresses n'est pas une question de correction fonctionnelle mais d'hygiène, et elle évite qu'un cache saturé n'expulse les pages réellement utiles. Sur un cache disposant d'une taille maximale, cette expulsion se produit silencieusement et dégrade progressivement les performances sans qu'aucun réglage n'ait changé.

Les fragments dynamiques dans les pages en cache

C'est là que se joue la performance réelle d'une boutique. Bien traités, ces fragments permettent de mettre en cache l'immense majorité des pages sans aucun risque.

Le compteur du panier

Le nombre d'articles affiché dans l'en-tête est le fragment personnalisé le plus visible. WooCommerce propose nativement un mécanisme de rafraîchissement de ces éléments par appel asynchrone, mécanisme que les extensions de cache savent exploiter. Il faut cependant vérifier qu'il est actif, car il est parfois désactivé pour des raisons de performance, décision qui règle un problème en en créant un autre nettement plus gênant pour le client. Le compromis raisonnable consiste à conserver le mécanisme en limitant le nombre de fragments rafraîchis, plutôt qu'à le désactiver entièrement.

Le message de bienvenue

Un bandeau saluant le client par son prénom sur une page mise en cache affichera le prénom du visiteur précédent. Ce genre de personnalisation cosmétique coûte cher en contraintes et apporte peu, et la question à se poser est de savoir si l'élément justifie réellement de compliquer toute la configuration. Lorsqu'il est conservé, il doit être chargé séparément comme le compteur de panier, et non produit dans le corps de la page.

Les prix personnalisés

Sur une boutique appliquant des tarifs par client ou par groupe, les prix affichés sur les listes et les fiches deviennent personnels, ce qui rend le cache de page inopérant en l'état. Deux solutions existent : mettre en cache par groupe tarifaire, en incluant le groupe dans la clé de cache, ou charger les prix par appel séparé. La première est plus performante et suppose que le nombre de groupes reste faible, la seconde fonctionne toujours mais dégrade l'affichage initial. Le choix dépend surtout de la part de trafic concernée : si la majorité des visiteurs voit le prix public, la première approche est nettement préférable.

Les stocks affichés

Une mention de disponibilité figée par un cache de plusieurs heures induit le client en erreur et provoque des commandes impossibles à honorer. Deux approches se combinent utilement : purger le cache de la fiche produit lors d'un changement de stock, ce qui est simple à déclencher, et afficher une mention de disponibilité générique plutôt qu'un nombre exact, ce qui réduit fortement la sensibilité au décalage sans nuire à l'information du client. Une mention indiquant simplement que le produit est disponible, sans quantité, reste vraie plus longtemps et suffit à la décision d'achat dans la plupart des cas.

Les éléments de recommandation

Les blocs de produits vus récemment ou recommandés en fonction du parcours sont personnels par nature. Ils doivent être chargés après le rendu de la page, ce qui présente l'avantage supplémentaire de ne pas retarder l'affichage du contenu principal. Leur absence temporaire sur une page en cours de chargement ne gêne personne, alors qu'un bloc figé montrant les produits consultés par quelqu'un d'autre produit une impression désagréable. Ce défaut est en outre difficile à repérer en interne, chacun voyant ses propres produits lors des tests.

Le tunnel et ses interceptions

Tout traitement personnalisé posé dans le parcours d'achat interagit avec le cache, et un code correct peut donner des résultats faux uniquement parce que la page a été servie depuis un enregistrement. Cette interaction doit être prise en compte dès l'écriture du code, et non découverte en production, sujet que nous développons dans notre article sur les hooks du tunnel de commande WooCommerce.

Configurer et vérifier

La configuration se fait en quelques minutes, la vérification demande une méthode, et c'est elle qui distingue une boutique correctement réglée d'une boutique qui fonctionne par chance.

Exclure explicitement plutôt que se fier aux réglages par défaut

Les extensions de cache détectent les pages sensibles d'une boutique par leur identifiant, ce qui fonctionne tant que les pages sont celles créées à l'installation. Un site dont les pages de panier ou de commande ont été recréées, renommées ou remplacées par des pages construites avec l'éditeur de blocs peut échapper à cette détection. Écrire explicitement les chemins à exclure prend deux minutes et supprime cette incertitude définitivement.

Purger au bon moment

Le cache d'une fiche produit doit être purgé lors d'une modification de prix, de stock ou de description. Les extensions le gèrent en général correctement pour les modifications faites dans l'administration, mais pas toujours pour celles provenant d'une synchronisation externe ou d'une interface de programmation. Sur une boutique alimentée par un système de gestion, ce point doit être vérifié explicitement, faute de quoi les prix affichés peuvent rester périmés plusieurs heures. Le test consiste à modifier un prix depuis la source externe puis à vérifier la fiche en navigation privée quelques secondes plus tard.

Vérifier en navigation privée

Le contrôle le plus simple consiste à parcourir la boutique dans une fenêtre de navigation privée, à ajouter un article au panier, à vérifier que le compteur se met à jour, puis à ouvrir une seconde fenêtre privée et à s'assurer que le panier y est vide. Ce test de trois minutes détecte la quasi totalité des configurations dangereuses et devrait être effectué après chaque modification de la configuration du cache. Il vaut mieux le mener sur un téléphone en plus d'un ordinateur, certaines configurations traitant différemment les requêtes selon le terminal.

Lire les en-têtes de réponse

Les extensions de cache ajoutent un en-tête indiquant si la réponse provient du cache. Le contrôle consiste à demander successivement une fiche produit, qui doit être servie depuis le cache, et la page de panier, qui ne doit pas l'être. Cette vérification objective vaut mieux que toute impression, et elle se fait en quelques secondes avec les outils de développement du navigateur ou une commande en ligne.

Surveiller après chaque mise à jour

Une mise à jour majeure de la boutique, de l'extension de cache ou d'un module de tarification peut modifier les conditions de mise en cache sans le signaler. Le test de navigation privée doit donc être rejoué après chaque intervention importante. Cette discipline évite la découverte d'un incident par un client, situation où le coût de l'incident dépasse largement le temps qu'aurait pris la vérification.

Distinguer le cache de pages des autres caches

Un site utilise en général plusieurs caches superposés : cache de pages, cache d'objets, cache de requêtes, cache du navigateur, cache d'un service de diffusion. Un symptôme de contenu périmé peut venir de n'importe lequel, et le diagnostic consiste à les désactiver un par un plutôt qu'à tous les vider simultanément. Cette méthode paraît lente et reste bien plus rapide que de purger l'ensemble sans jamais comprendre lequel était en cause.