Tu as corrigé, mais l'écran ne change pas — le fonctionnement du cache

Cet article traite du cas où tu as corrigé, mais l'écran ne change pas.

Tu as corrigé le code et déployé, mais quand tu ouvres la page, c'est encore la version précédente.

La cause n'est en général pas le code, mais une ancienne copie qui subsiste quelque part.

Selon que tu es le seul à voir l'ancienne version ou que tout le monde la voit, tu sais où elle subsiste.

Qu'est-ce qu'un cache — renvoyer une copie gardée au lieu d'aller la rechercher

Le cache (cache : un mécanisme qui garde à proximité ce qui a été récupéré une fois et qui, ensuite, le renvoie sans aller le rechercher) existe pour ne pas aller chercher la même chose encore et encore.

Ce qui a été récupéré une fois est gardé à portée de main, et à partir de la deuxième fois, c'est cela qui sert.

En échange de la rapidité, il existe un laps de temps pendant lequel la mise à jour passe inaperçue.

Cette durée de conservation est la durée de validité (max-age : le temps pendant lequel une copie gardée peut servir sans aller la rechercher).

Tant que la durée de validité n'a pas expiré, la copie locale continue de servir même si tu corriges le serveur.

Plus une chose change rarement, comme les images et le CSS, plus la durée est réglée longue.

Une correction ne s'affiche pas tant que la durée de validité n'a pas expiré.

Le cache renvoie une ancienne copie

Un cache garde à proximité ce qui a été récupéré une fois et le renvoie ensuite.

C'est plus rapide, puisqu'il ne va pas chercher à chaque fois, mais il ne remarque pas la mise à jour du serveur entre-temps : d'où la correction qui ne s'affiche pas.

Les trois endroits où se pose une copie — chez toi, en cours de distribution, dans le serveur

Une copie ne se pose pas à un seul endroit.

Il y a trois endroits, imbriqués, du plus proche de l'utilisateur vers l'extérieur.

Le plus intérieur, la copie que détient ton propre navigateur, est le cache du navigateur (browser cache).

Le deuxième, le CDN (Content Delivery Network : un mécanisme qui pose des copies près des utilisateurs et les distribue depuis là), est intégré d'origine dans beaucoup de cibles de déploiement.

Ces trois endroits diffèrent par la façon de les effacer et par la portée de l'effet.

L'opération qui fait supprimer la copie du CDN est la purge : supprimer la copie que détient le système de distribution et la faire récupérer à nouveau.

Certaines configurations purgent automatiquement à chaque déploiement.

Ce qu'est un rechargement forcé

Avec un rechargement ordinaire, la copie locale sert parfois telle quelle.

L'opération qui force une nouvelle récupération s'appelle le rechargement forcé (hard reload) ; si tu veux seulement vérifier, ouvrir la page dans une fenêtre qui ne garde pas d'historique fait la même chose.

Isoler la cause selon que tu es le seul à voir l'ancienne version ou que tout le monde la voit

Plutôt que d'essayer les trois endroits de haut en bas, vérifier d'abord la portée va plus vite.

Ce que tu regardes, c'est si d'autres personnes que toi voient aussi l'ancienne version.

Si tu es le seul, la cause n'est nulle part ailleurs que dans ton propre navigateur.

Si les autres voient aussi l'ancienne version, tu auras beau recharger de ton côté, rien ne changera.

Le cas du bas est celui où les nouveaux fichiers ne sont jamais arrivés jusqu'au serveur public.

Si le build a échoué, ce sont encore les fichiers générés précédents qui sont publiés.

Une correction obtenue par un rechargement n'est pas forcément une solution

Recharger de ton côté te donne la nouvelle version, mais cela n'a fait que remplacer la copie de ta seule machine.

Sur les appareils des utilisateurs, l'ancienne copie reste jusqu'à l'expiration de la durée de validité.

Changer le nom du fichier empêche l'ancienne copie de servir

Plutôt que de passer partout pour effacer, il existe un moyen d'empêcher purement et simplement que l'ancienne copie serve.

Il consiste à changer le nom du fichier en même temps que son contenu.

Si tu remplaces une partie du nom du fichier par des caractères calculés à partir du contenu, le nom change chaque fois que le contenu change.

Si le nom est différent, la copie locale est un autre fichier et elle ne sert pas.

Ce travail de nommage est fait automatiquement au moment du build.

Tu n'as pas besoin d'inventer les noms toi-même.

Seul index.html, le point d'entrée, ne peut pas changer de nom : tu gardes donc sa durée de validité courte.

Dès que les noms des fichiers qu'il charge sont nouveaux, tout le reste arrive automatiquement dans sa nouvelle version.

Dès que c'est trouvé à une étape antérieure, la recherche ne va pas plus loin.

Donc si un seul endroit détient encore une ancienne copie, la nouvelle version n'arrive pas.

Changer le nom est plus sûr que de passer partout pour effacer

Si le nom du fichier change en même temps que son contenu, la copie locale est un autre fichier et elle ne sert pas.

Ce nommage est fait automatiquement par le build : tu gardes donc une durée de validité courte seulement pour le fichier d'entrée, dont le nom ne peut pas changer.