Qu’est-ce que le contournement du cache ?

Le contournement du cache consiste à publier un contenu modifié sous une nouvelle URL, généralement en plaçant une empreinte du contenu ou un identifiant de version dans le nom du fichier, le chemin ou la chaîne de requête. Les caches HTTP recherchent les réponses stockées par URL. Une requête visant la nouvelle adresse ne peut donc pas recevoir la copie stockée sous l’ancienne, tant qu’aucun cache n’est configuré pour ignorer la partie de l’URL qui a changé.

Un cache HTTP réutilise une réponse stockée tant qu’elle est fraîche, sans contacter l’origine. Un fichier servi avec une valeur élevée pour max-age ne génère donc plus les requêtes qui permettraient au serveur de le remplacer. Il est généralement possible de purger un CDN, mais cette purge n’atteint pas les copies déjà détenues par les navigateurs. Le contournement du cache évite ces deux problèmes. Selon la spécification, une clé de cache contient au moins la méthode de la requête et l’URL ; certains CDN peuvent être configurés pour en exclure la chaîne de requête. Une URL dont la clé n’a pas été stockée ne dispose d’aucune réponse stockée : chaque cache doit donc transmettre la requête vers l’origine. En pratique, les fichiers versionnés reçoivent une valeur élevée pour max-age (l’exemple de MDN utilise un an, max-age=31536000), éventuellement avec immutable, tandis que le document qui les référence est servi avec no-cache. Un cache doit ainsi revalider ce document avant de le réutiliser, et un nouveau chargement de la page reçoit les noms de fichiers actuels. MDN précise que no-cache ne garantit pas la revalidation lors de la navigation dans l’historique : le bouton Retour peut donc restaurer une page antérieure. Les outils de regroupement tels que webpack et Vite génèrent les noms de fichiers contenant une empreinte lors de la compilation.

Nom de fichier ou chaîne de requête ? app.3f9a1c.js et app.js?v=3f9a1c modifient tous deux l’URL, mais une version placée dans la chaîne de requête ne fonctionne que si chaque cache sur le trajet conserve cette chaîne dans sa clé de cache. C’est le cas du niveau de mise en cache Standard utilisé par défaut par Cloudflare, tandis que son niveau Ignore Query String sert une seule copie en cache d’un fichier statique, quelle que soit la valeur de la chaîne de requête. Amazon CloudFront ne met en cache selon la chaîne de requête que si la distribution est configurée à cet effet, et les buckets backend de Google Cloud CDN exigent que le paramètre de version figure dans une liste d’inclusion. Une version placée dans la chaîne de requête tend aussi à laisser à l’origine un seul fichier, que chaque nouvelle version écrase sur place. Ainsi, une page issue de la version précédente qui demande son ancienne URL ?v= après une absence en cache reçoit le fichier de la nouvelle version. Les recommandations de Google pour Cloud CDN préconisent plutôt des noms de fichiers uniques, car un fichier mis à jour sur place peut être mis en cache alors qu’il est incomplet.
Les fichiers inchangés conservent-ils leur URL d’une version à l’autre ? Avec une empreinte du contenu, oui, à condition que la compilation produise des octets identiques. Un numéro de version ou un horodatage appliqué à chaque chemin modifie toutes les URL à chaque nouvelle version et écarte les copies en cache des fichiers qui n’ont pas changé. L’empreinte d’un fichier peut tout de même changer sans que son code source ait été modifié : le guide de mise en cache de webpack montre que la valeur de [contenthash] d’un fichier regroupant les dépendances tierces change après l’ajout d’un module sans rapport, car les identifiants des modules suivaient l’ordre de résolution. Le guide précise que le mode production de webpack 5 utilise par défaut des identifiants de modules déterministes et déplace également le code d’exécution dans un fragment distinct.
Dans quel ordre effectuer un déploiement ? Téléversez d’abord les nouveaux fichiers versionnés et publiez en dernier le document qui les référence. Les recommandations de Google pour Cloud CDN soulignent qu’il est crucial de téléverser les dépendances avant les fichiers qui les référencent. Conservez également les fichiers de la version précédente : une page chargée avant le déploiement demande toujours les anciens noms, et webpack comme Vite documentent des échecs de chargement de fragments ou des erreurs d’importation lorsqu’un déploiement supprime ces fichiers. Le guide de webpack suggère de laisser le CDN faire expirer les anciens fichiers après environ un jour plutôt qu’au déploiement suivant, et de recharger la page au plus une fois lorsqu’un fragment ne se charge toujours pas, car un onglet peut rester ouvert plus longtemps que la durée de conservation.
Qu’apporte immutable à une valeur élevée pour max-age ? Cette directive indique aux clients de ne pas revalider le fichier au rechargement tant qu’il est encore frais, ce qui évite des requêtes conditionnelles qui ne renverraient que 304. Elle ne prolonge pas la durée de validité et n’est correcte que si le fichier situé à cette URL ne change pas tant que la réponse est fraîche, comme avec un nom de fichier contenant une empreinte et jamais écrasé. MDN précise que Chrome n’implémente pas cette directive et évite plutôt de revalider les sous-ressources au rechargement.

Utilisez le contournement du cache pour les sous-ressources telles que les scripts, les feuilles de style et les images que les navigateurs et les CDN doivent conserver longtemps tout en récupérant leur nouvelle version juste après une publication. Cette technique ne peut pas s’appliquer à une URL qui doit rester identique, comme celle du document HTML qui référence ces fichiers ; servez ce document avec no-cache pour que les navigateurs le revalident à chaque nouveau chargement de page. Si le CDN est configuré pour servir le document depuis son propre cache sans le revalider, purgez également cette copie à chaque déploiement ; une purge seule ne met pas à jour les navigateurs. Chaque nouvelle clé de cache démarre à froid : chaque cache doit récupérer le fichier une fois, depuis l’origine ou depuis un cache plus proche de l’origine, avant de pouvoir le servir.

Le Smart CDN de Transloadit attribue à chaque variante transformée sa propre URL : le Workspace, le nom du Template, le chemin du fichier source et les paramètres de transformation font tous partie de l’adresse tlcdn.com. Demander une taille ou un format différent modifie donc l’URL et produit une version de diffusion distincte en cache. À l’inverse, un succès du cache pour la même URL réutilise le résultat en cache au lieu d’exécuter à nouveau le Template. Pour les URL signées, la durée de validité effective d’une réponse en cache est limitée par la durée de validité restante de la signature.

Les pages liées ici ne décrivent ni une opération de purge ni ce qui arrive à un résultat en cache lorsque l’original est remplacé sans modifier le chemin du fichier. Stocker un original de remplacement sous un nouveau chemin modifie l’URL du Smart CDN ; testez le cas où le chemin reste inchangé dans votre propre Workspace avant de vous y fier.

Explorer les capacités de diffusion de Transloadit

Qu’est-ce que le contournement du cache ?

Fonctionnement du contournement du cache

Points clés

Quand le contournement du cache est utile

Comment Transloadit facilite le contournement du cache

Références

Transformer vos connaissances sur les médias en une chaîne de traitement opérationnelle