Qu’est-ce que la mise en cache de contenu ?

La mise en cache de contenu stocke des copies réutilisables de réponses, de métadonnées ou de ressources générées à proximité des clients qui les utiliseront ensuite. Les requêtes ultérieures peuvent ainsi éviter de répéter les calculs ou la récupération depuis l’origine.

Un cache HTTP stocke une réponse sous une clé de cache. Cette clé comprend au minimum la méthode et l’URL de la requête, et peut être complétée par les en-têtes de requête que la réponse désigne dans Vary ou par la configuration du CDN. Tant qu’une réponse stockée est fraîche, le cache peut répondre à partir de celle-ci sans contacter l’origine. Une fois la réponse périmée, le cache vérifie normalement auprès de l’origine avant de la réutiliser, sauf si une directive ou sa configuration autorise à servir la copie périmée. Lorsque l’origine a envoyé un validateur (ETag ou Last-Modified), cette vérification prend la forme d’une requête conditionnelle, et une réponse 304 Not Modified permet au cache de continuer à utiliser la copie sans télécharger à nouveau le corps. Deux types de caches suivent des règles différentes. Un cache privé, généralement celui du navigateur, appartient à un seul utilisateur et peut conserver des réponses personnalisées. Un cache partagé se situe entre les clients et l’origine et sert de nombreux utilisateurs ; les CDN et les proxys inverses sont des caches partagés exploités par l’opérateur du site, que MDN appelle des caches gérés. Cache-Control définit une durée de validité explicite avec max-age et peut traiter séparément les deux types : private indique aux caches partagés de ne pas stocker une réponse, et s-maxage prime sur max-age uniquement pour les caches partagés. Un cache géré y ajoute sa propre configuration et ses opérations de purge. Une purge supprime la copie au niveau du CDN, mais les copies déjà détenues par les navigateurs restent présentes jusqu’à leur expiration. C’est pourquoi les ressources qui ne changent jamais sont publiées sous des URL versionnées avec de longues durées de validité, tandis que les URL qui doivent rester stables font l’objet de revalidations.

no-cache ou no-store ? no-store indique à tous les caches, privés ou partagés, de ne pas conserver la réponse. no-cache autorise le stockage de la réponse, mais interdit sa réutilisation sans revalidation préalable auprès de l’origine. Lorsque la réponse comporte un validateur tel que ETag ou Last-Modified et que l’origine répond aux requêtes conditionnelles, une ressource inchangée ne nécessite qu’un bref échange 304 Not Modified plutôt qu’un téléchargement complet ; sans ces mécanismes, une réutilisation nécessite normalement de télécharger à nouveau la réponse complète. Aucune des deux directives ne garantit à elle seule la confidentialité : no-cache autorise toujours le stockage, et la RFC 9111 précise que no-store n’est pas un mécanisme fiable ou suffisant pour garantir la confidentialité. Un CDN peut également traiter no-cache différemment de ce que prévoit la RFC. Cloudflare indique dans sa documentation que, lorsque sa fonctionnalité Origin Cache Control est désactivée, il ne met jamais en cache une réponse no-cache, et que, lorsque cette fonctionnalité est activée, il met la réponse en cache et la revalide systématiquement.
Une réponse sans Cache-Control reste-t-elle hors du cache ? Pas de manière fiable. Lorsqu’aucune durée de validité explicite n’est indiquée, la RFC 9111 autorise un cache à en estimer une, généralement comme une fraction du temps écoulé depuis Last-Modified (l’exemple de la RFC est 10 %), et encourage les serveurs d’origine à envoyer des directives explicites s’ils souhaitent empêcher la mise en cache. Les CDN ajoutent leurs propres comportements par défaut. Cloudflare se fonde sur l’extension du fichier, et non sur son type MIME : pour une extension figurant dans sa liste par défaut, comme JPG, PNG, CSS ou JS, il met en cache une réponse 200 pendant une durée par défaut, même si elle ne contient ni Cache-Control ni Expires, et il ne met pas en cache le HTML ou le JSON, sauf si une règle l’active. Ce comportement par défaut dépend de l’extension de l’URL, et une règle de cache peut l’étendre à tous les contenus. Ne vous y fiez donc pas pour maintenir les pages personnalisées hors du cache. Envoyez une politique explicite avec chaque réponse et consultez le comportement par défaut du CDN avant de vous fier à l’un ou à l’autre.
Comment maintenir les réponses personnalisées hors d’un cache partagé ? Envoyez Cache-Control: private, qui indique aux caches partagés, tels que les CDN, de ne pas stocker la réponse, tout en autorisant le navigateur de l’utilisateur à le faire ; pour les pages personnalisées après connexion, MDN recommande Cache-Control: no-cache, private, afin que le navigateur revalide lui aussi la réponse avant de la réutiliser. HTTP ne protège automatiquement qu’un seul cas : un cache partagé ne doit pas réutiliser une réponse à une requête contenant Authorization, sauf si la réponse l’autorise explicitement avec public, s-maxage ou must-revalidate. Une réponse personnalisée à l’aide d’un cookie ne bénéficie pas de cette protection, et MDN précise qu’un cookie seul ne rend pas une réponse privée. Un CDN ne respecte la directive que tant qu’il suit les en-têtes du serveur d’origine : Cloudflare, par exemple, indique respecter les en-têtes de cache du serveur d’origine, sauf si une règle de cache Edge Cache TTL les remplace. Vérifiez donc les règles du CDN qui s’appliquent aux URL personnalisées. private contrôle uniquement les endroits où une réponse peut être stockée ; la RFC 9111 précise que cette directive ne peut pas garantir la confidentialité du contenu.
Que doit contenir la clé de cache pour les variantes de médias ? Chaque donnée d’entrée qui modifie le résultat, et rien d’autre. Lorsque la variante dépend d’un en-tête de requête, par exemple un format d’image négocié via Accept, la réponse doit mentionner cet en-tête dans Vary ; selon la RFC 9111, un cache ne peut alors réutiliser une réponse stockée que pour les requêtes dont les en-têtes mentionnés correspondent. Un CDN n’applique pas nécessairement cette règle par défaut : Cloudflare indique ne pas tenir compte de Vary dans ses décisions de mise en cache, sauf pour Vary: Accept-Encoding, à moins que son paramètre de règle de cache Vary ou sa fonctionnalité Vary for images ne soit configuré. Vérifiez que le CDN fait varier son cache en fonction de l’en-tête avant de vous fier uniquement à Vary. Lorsque la variante dépend de paramètres d’URL, tels que la largeur, le recadrage ou le format, ces paramètres doivent rester dans la clé, et les comportements par défaut des CDN diffèrent ici aussi : la clé de cache par défaut de Cloudflare inclut la chaîne de requête, tandis qu’Amazon CloudFront ne fonde pas sa mise en cache sur les paramètres de la chaîne de requête lorsqu’il n’est pas configuré pour transmettre ces chaînes au serveur d’origine. Une clé qui omet une donnée d’entrée sert à un demandeur la version dérivée destinée à un autre. Une clé qui contient plus d’éléments que nécessaire stocke des doublons : CloudFront conseille de ne fonder la mise en cache que sur les paramètres pour lesquels le serveur d’origine renvoie des versions différentes, et précise qu’il traite comme des objets distincts les chaînes de requête dont la casse ou l’ordre diffèrent.

Mettez en cache les médias et variantes fréquemment demandés lorsque la réduction de la latence et de la charge du serveur d’origine prime sur les exigences de fraîcheur. Des clés ou des règles d’invalidation incorrectes peuvent entraîner la diffusion de contenus périmés, privés ou ne correspondant pas à la requête.

Le Smart CDN de Transloadit met en cache le résultat d’un Template en périphérie du réseau. Si le résultat est absent du cache, il importe l’original depuis votre stockage et exécute l’Assembly ; les requêtes suivantes pour la même URL reçoivent la copie en cache sans nouvelle exécution de l’Assembly. Les paramètres de transformation font partie de l’URL : chaque combinaison est donc demandée et mise en cache comme un rendu distinct.

Le temps de la première requête pour chaque nouvelle URL comprend la récupération et le traitement de l’original. Pour les URL signées du Smart CDN, 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 ; une expiration proche raccourcit donc aussi la durée de réutilisation d’un résultat.

Explorer les capacités de diffusion de Transloadit

Qu’est-ce que la mise en cache de contenu ?

Comment fonctionne la mise en cache de contenu

Points clés

Quand la mise en cache de contenu est importante

Comment Transloadit facilite la mise en cache de contenu

Références

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