Qu’est-ce que l’invalidation du cache ?

L’invalidation du cache supprime des entrées en cache ou les marque comme périmées avant leur expiration normale. Les requêtes ultérieures déclenchent une nouvelle récupération ou une revalidation auprès de l’origine. Une entrée uniquement marquée comme périmée peut encore être servie entre-temps, selon la politique du cache.

L’invalidation modifie l’état du cache sans obliger les éditeurs à attendre la fin des durées de fraîcheur. HTTP offre lui-même peu de mécanismes à cet effet : un cache invalide une URL lorsqu’une requête non sûre visant cette URL, telle que PUT, POST ou DELETE, le traverse et aboutit. Cela n’affecte que les caches situés sur le chemin de cette requête, et aucune directive Cache-Control ne peut supprimer une réponse déjà stockée. Les CDN exposent donc leur propre plan de contrôle, qui peut cibler des URL exactes, des préfixes, des étiquettes ou une distribution entière. Les nœuds concernés évincent ensuite l’objet ou exigent une revalidation. Une purge stricte supprime l’objet : la requête suivante ne le trouve donc pas en cache, le récupère intégralement et le remet en cache. Une purge douce conserve l’objet et le marque comme périmé : la requête suivante le revalide et peut réutiliser le corps stocké lorsque l’origine répond 304 Not Modified. La terminologie varie selon les fournisseurs : Cloudflare appelle l’opération douce « invalidation » et l’opération stricte « purge », tandis que ce qu’Amazon CloudFront et Google Cloud CDN appellent une invalidation supprime l’objet.

La purge de l’URL d’origine supprime-t-elle aussi ses variantes redimensionnées ou dans d’autres formats ? Uniquement si le fournisseur les traite comme un seul objet ou si vous les ciblez ensemble. Commencez donc par examiner en quoi les URL des variantes diffèrent de l’originale. Sur les services CDN de Fastly, Image Optimizer purge l’original et toutes ses variantes lorsque la requête de purge ne contient aucun paramètre de transformation ; sur les services Fastly Compute, le même ensemble est purgé via l’API Purge à l’aide d’une clé de substitution commune. Cloudflare purge toutes les variantes en cache d’une URL d’image qui utilise sa fonctionnalité Vary for Images. Amazon CloudFront, en revanche, exige que la chaîne de requête figure dans le chemin d’invalidation lorsque la distribution transmet les chaînes de requête à l’origine, ou qu’un caractère générique * soit placé à la fin pour couvrir toutes les chaînes de requête. Une purge qui désigne une seule URL n’atteint pas les variantes publiées sous d’autres chemins. La couverture d’autres noms d’hôte dépend du fournisseur : une invalidation de chemin dans Google Cloud CDN s’applique à tous les noms d’hôte de l’équilibreur de charge, sauf si un hôte est spécifié. Les variantes hors du sélecteur nécessitent une étiquette de cache ou une clé de substitution commune, une purge par préfixe ou une liste explicite.
Dans quel ordre procéder, et comment savoir si cela a fonctionné ? Corrigez d’abord le contenu à l’origine : Cloudflare et Google Cloud CDN avertissent tous deux que, sans cela, la requête suivante peut remettre l’ancienne version en cache. Une réponse positive de l’API ne prouve pas la suppression. Cloudflare précise qu’une réponse HTTP 200 à une requête de purge confirme sa réception, sans prouver qu’un élément était en cache ou a été évincé, et recommande de demander la ressource pour vérifier que CF-Cache-Status n’a plus la valeur HIT. Cet en-tête est un indice, pas une preuve : la première requête après une purge indique MISS, puis les suivantes indiquent HIT pour la copie remise en cache, tandis que STALE ou UPDATING signifie qu’une copie stockée ayant expiré a été servie. Demandez l’original et chaque variante concernée avec un client sans cache local, puis vérifiez que le contenu renvoyé est bien la nouvelle version. Chaque réponse décrit un seul cache : Google Cloud CDN indique qu’une invalidation peut être signalée comme terminée alors qu’un petit nombre de caches ne l’ont pas encore traitée, une situation rare qui se résout d’elle-même. Sur CloudFront, une invalidation envoyée ne peut pas être annulée ; vérifiez donc les chemins avant de l’envoyer.
Une purge du CDN met-elle à jour les copies détenues par les navigateurs ? Non. Google Cloud CDN précise que les invalidations n’affectent pas les copies présentes dans les caches des navigateurs web ou dans ceux exploités par des fournisseurs d’accès à Internet tiers. Le guide CloudFront indique qu’un utilisateur peut continuer à voir l’ancienne version jusqu’à son expiration dans ces caches. Pour contourner ces copies plus rapidement, publiez le fichier corrigé sous un nouveau nom ou un nouveau chemin et mettez à jour les pages qui y font référence. C’est l’une des raisons pour lesquelles CloudFront recommande les noms de fichiers versionnés plutôt que l’invalidation pour les fichiers fréquemment mis à jour. Les copies stockées sous l’ancienne URL ne sont pas supprimées : les pages qui font référence à la nouvelle URL cessent simplement de les demander. Modifier uniquement la chaîne de requête est moins fiable, car cela ne fonctionne que si chaque cache sur le chemin inclut cette chaîne dans sa clé de cache. Avec le niveau de cache Ignore Query String de Cloudflare, par exemple, les URL qui ne diffèrent que par leur chaîne de requête partagent un seul objet en cache. Une URL qui doit rester identique et dont le contenu peut nécessiter une correction sur place ne devrait pas être associée à une longue durée de validité dans le cache du navigateur.
Purge stricte ou purge douce, et sur quelle étendue ? Après une purge stricte de l’ensemble du cache, les requêtes sont servies depuis l’origine jusqu’au repeuplement du cache. Cloudflare avertit que, sur les sites très fréquentés comportant de nombreuses ressources, cela peut provoquer un pic important de requêtes vers l’origine, ralentir le site et surcharger l’origine. Google conseille de n’invalider que le strict nécessaire. Une purge douce permet à la requête suivante de revalider et de réutiliser le corps stocké, ce qui ne fonctionne que si l’origine envoie ETag ou Last-Modified et répond aux requêtes conditionnelles. Cloudflare la suggère pour actualiser un contenu qui n’a peut-être pas changé, comme un groupe de ressources partageant une étiquette de cache. En contrepartie, du contenu marqué comme périmé peut encore parvenir aux visiteurs : Fastly décrit un objet ayant subi une purge douce comme étant servi dans son état périmé pendant la récupération de sa version mise à jour, et Cloudflare peut servir du contenu invalidé et périmé lorsque l’origine renvoie une erreur 5xx ou est inaccessible. Utilisez une purge stricte lorsque l’ancien contenu ne doit plus jamais être servi. Le regroupement des requêtes et un niveau de cache de protection de l’origine réduisent le nombre de requêtes de repeuplement qui atteignent l’origine.

Invalidez une ressource lorsqu’une correction urgente doit se propager avant l’expiration de sa durée de vie. Une invalidation sur un CDN n’atteint pas les copies déjà détenues par les navigateurs ou d’autres caches en aval. Il est donc préférable de publier le contenu régulièrement modifié sous des noms de fichiers versionnés. Purgez le plus petit ensemble qui couvre la modification, car tous les éléments supprimés par une purge étendue doivent être récupérés à nouveau depuis l’origine à mesure que les requêtes arrivent.

Le Smart CDN de Transloadit met en cache chaque résultat transformé sous son URL tlcdn.com. La documentation décrit des contrôles qui limitent à l’avance la durée de réutilisation d’un résultat : le paramètre cache_duration du Robot /file/serve définit les durées de validité dans le navigateur et les caches partagés transmises avec le résultat. Pour les URL signées, la durée de validité effective du cache est limitée par la durée de validité restante de la signature.

Les pages liées ici ne décrivent aucune opération de purge ou d’invalidation pour le Smart CDN, ni ce qui arrive à un résultat en cache lorsque l’original est remplacé sans modifier le chemin du fichier. Une URL du Smart CDN désigne un fichier source et les paramètres de transformation lus par votre Template. Un chemin de fichier différent ou une valeur différente pour l’un de ces paramètres demande donc une autre version de rendu. Ces pages n’indiquent pas qu’un paramètre supplémentaire sans rapport permet de contourner un résultat en cache ; testez le cas d’un chemin inchangé sur votre propre Workspace avant de vous y fier.

Explorer les capacités de diffusion de Transloadit

Qu’est-ce que l’invalidation du cache ?

Fonctionnement de l’invalidation du cache

Points clés

Quand l’invalidation du cache est utile

Comment Transloadit facilite l’invalidation du cache

Références

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