Vos clients voient l'ancienne version de la boutique : cache du navigateur et versionnage

Vous avez corrigé un défaut de design sur mobile, vérifié que tout s'affiche correctement et considérez l'affaire réglée. Le lendemain, un client vous envoie une capture d'écran avec la page déformée, exactement comme avant. Vous n'arrivez pas à le reproduire. Le client ne se trompe pas : son navigateur utilise toujours l'ancienne feuille de style qu'il a enregistrée lors de sa dernière visite de la boutique.

C'est l'un des problèmes les plus déroutants de la maintenance d'une boutique, car il n'arrive jamais à la personne qui fait la modification. Voyons pourquoi il se produit et comment l'éviter.

Pourquoi le navigateur conserve les fichiers

Pour que les pages se chargent vite, le navigateur garde une copie des fichiers qui changent peu : feuilles de style, scripts, images et polices. La fois suivante, il utilise sa copie au lieu de les demander au serveur. La durée de conservation est fixée par les en-têtes de cache que le serveur envoie avec chaque fichier.

Pour une boutique, conserver ces fichiers longtemps est une bonne chose : moins de requêtes, des pages plus rapides, moins de charge sur le serveur. Le problème apparaît quand vous modifiez l'un d'eux et que son adresse reste la même. Le navigateur n'a aucun moyen de savoir qu'il existe une nouvelle version, et il continue d'utiliser celle qu'il a jusqu'à son expiration.

Les symptômes

• Une mise en page cassée ou à moitié appliquée chez certains clients seulement.
• Un bouton qui ne fait rien parce que le HTML est nouveau mais le JavaScript ancien (ou l'inverse).
• Des erreurs JavaScript dans la console qui n'apparaissent pas dans votre navigateur.
• Des réclamations qui disparaissent d'elles-mêmes au bout de quelques jours, quand les copies expirent.
• Le classique « chez moi, ça marche » du développeur, qui recharge avec le cache vidé.

Ce n'est pas seulement le navigateur

Entre votre serveur et le client, plusieurs couches peuvent conserver des copies :

• Le cache de PrestaShop des fichiers combinés. Si vous avez activé l'option qui combine, compresse et met en cache le CSS et le JS, la boutique sert des fichiers générés à partir des vôtres. Si vous modifiez un fichier source et que la version combinée n'est pas régénérée, personne ne voit le changement, pas même vous.
• Le cache des templates de Smarty, si vous avez modifié un template.
• Un cache de page, dans un module ou sur le serveur, qui conserve le HTML avec les anciennes adresses.
• Un CDN ou un proxy devant la boutique, avec sa propre copie des fichiers.
• Le navigateur de chaque client.

Vous contrôlez les quatre premières : les vider fait partie de toute modification du design. Pas la dernière : vous ne pouvez pas demander à chaque client de vider son cache.

La solution : changer l'adresse quand le fichier change

La technique standard s'appelle le versionnage (ou cache busting). Elle consiste à inclure dans l'adresse du fichier un élément qui change chaque fois que son contenu change. Par exemple, en ajoutant un paramètre : custom.css?v=20 devient custom.css?v=21. Pour le navigateur, c'est une nouvelle adresse, il la télécharge donc ; et tant qu'elle ne change pas, il peut la conserver aussi longtemps qu'il le souhaite.

Il existe plusieurs façons de calculer ce marqueur :

• Par la date de modification du fichier. Automatique : chaque fois que vous enregistrez le fichier, il change. Seul ce qui a changé est téléchargé à nouveau.
• Par une empreinte du contenu. Tout aussi automatique et plus précis, mais il faut la calculer.
• Un numéro de version global que vous incrémentez à chaque déploiement. Tout est téléchargé à nouveau, même si un seul fichier a changé.

Quand PrestaShop combine et compresse les fichiers, il génère déjà de nouveaux noms pour le fichier combiné lors de sa régénération. Mais toutes les boutiques n'utilisent pas cette option (elle pose parfois des problèmes avec l'ordre de chargement de certains modules) et elle ne couvre pas les fichiers chargés séparément.

Attention aux dates lors des déploiements

Le versionnage par date de modification a un piège : si vous envoyez les fichiers avec un outil qui conserve la date d'origine (certains logiciels FTP, certaines façons de déployer ou de restaurer des sauvegardes), le fichier change mais pas sa date, et le marqueur de version reste le même. Dans ces cas, vous devez pouvoir forcer une nouvelle version à la main après le déploiement.

Et si je réduis la durée du cache ?

C'est la tentation quand le problème se répète : configurer le serveur pour que le navigateur ne garde le CSS et le JS que quelques minutes, ou qu'il demande toujours s'il existe une nouvelle version. Cela fonctionne, mais vous le payez à chaque visite : plus de requêtes, plus d'attente sur mobile et plus de charge sur le serveur, même pour des fichiers qui ne changent pas pendant des mois. Avec le versionnage, vous pouvez faire exactement l'inverse : garder des durées de cache longues, ce qui favorise la vitesse, car lorsqu'un fichier change, son adresse change aussi.

Ce qu'il faut en revanche, c'est que le HTML des pages ne soit pas conservé longtemps dans le navigateur ni dans les couches intermédiaires, car c'est lui qui porte les adresses avec la version. Si l'ancien HTML reste en cache, il continuera de demander les anciens fichiers même s'ils sont versionnés.

Que faire après chaque modification du design

1. Videz le cache de PrestaShop (templates et fichiers combinés) depuis Paramètres avancés → Performances.
2. Si vous avez un cache de page ou un CDN, purgez-les.
3. Vérifiez que les adresses des CSS et JS modifiés portent un nouveau marqueur de version (dans le code source de la page).
4. Testez dans un navigateur avec lequel vous aviez déjà visité la boutique avant la modification, sans vider son cache : c'est ainsi que la voit un vrai client.
5. Testez sur mobile, qui conserve souvent des copies plus anciennes.

Comment le résoudre dans PrestaShop

Rekire Cache Buster ajoute un marqueur de version (?v=) à chaque fichier CSS et JS local du front-office, pour que le navigateur télécharge le nouveau dès qu'il change. Il propose deux modes : automatique, avec la version tirée de la date de modification de chaque fichier, ou manuel, avec un jeton unique que vous changez vous-même. Vous pouvez l'activer pour le CSS, pour le JS ou pour les deux, et le bouton Forcer le rechargement maintenant oblige tous les visiteurs à télécharger à nouveau le CSS et le JS après un déploiement, ce dont vous avez besoin si votre façon d'envoyer les fichiers conserve leurs dates. Il ne touche pas aux fichiers servis depuis un autre domaine ou un CDN, ni à ceux qui ont déjà leur propre version, et il ne combine ni ne compresse rien : l'ordre de chargement n'est donc pas modifié. Compatible avec PrestaShop 1.7, 8 et 9.