Qu’est-ce que le contenu statique ?

Le contenu statique est servi à partir d’une représentation stockée qui reste généralement identique d’une requête à l’autre. Il ne change que lorsque la ressource sous-jacente est mise à jour, plutôt que d’être généré à chaque requête.

Le contenu statique est une caractéristique du mode de diffusion : le serveur peut renvoyer des octets qui existent déjà, par exemple un fichier sur disque ou un objet dans un bucket, sans exécuter de logique applicative pour la requête. Le fichier peut avoir été écrit à la main, produit par une compilation ou exporté par une chaîne de traitement multimédia. « Statique » ne signifie donc pas qu’il ne change jamais, mais que le contenu change lorsque le fichier stocké est remplacé, pas lorsqu’une requête arrive. Deux mécanismes HTTP assurent donc l’essentiel du travail. La fraîcheur, définie avec Cache-Control, indique aux navigateurs et aux CDN pendant combien de temps ils peuvent réutiliser une copie sans demander de vérification. Les validateurs, un ETag ou une date Last-Modified, permettent à un cache de demander si sa copie est toujours à jour et de recevoir une réponse 304 sans corps si c’est le cas. Les images, segments vidéo, polices, feuilles de style, scripts et pages HTML prégénérées sont des contenus statiques typiques ; une réponse assemblée à chaque requête à partir de l’état de l’application est un contenu dynamique.

Un fichier statique est-il automatiquement mis en cache ? Pas de façon fiable, ni pour une durée prévisible. Sans fraîcheur explicitement définie par Cache-Control ou Expires, HTTP permet à un cache d’appliquer une fraîcheur heuristique : la RFC 9111 l’autorise à estimer une durée de vie à partir de Last-Modified et donne comme réglage typique 10 % du temps écoulé depuis la dernière modification. C’est pourquoi MDN recommande un en-tête Cache-Control explicite sur chaque réponse. Les CDN ajoutent leurs propres valeurs par défaut. Cloudflare, par exemple, met en cache selon l’extension du fichier et non selon le type MIME, ne met pas en cache le HTML ou le JSON par défaut et ne met pas en cache une réponse contenant Set-Cookie.
Un fichier statique doit-il conserver son URL lorsque son contenu change ? Décidez au cas par cas. Un fichier dont l’URL change avec le contenu, comme un bundle dont le nom contient une empreinte, peut être servi avec un max-age long (l’exemple de MDN utilise un an) et immutable, car une nouvelle version arrive sous une nouvelle URL. Un fichier qui doit conserver son URL, comme une page HTML, ne devrait pas avoir une longue durée de vie : mettre à jour le fichier sur le serveur ne remplace pas une copie encore fraîche déjà stockée par un navigateur. Comme le souligne MDN, les requêtes correspondantes ne parviennent plus au serveur, et le navigateur peut donc continuer à utiliser cette copie jusqu’à l’expiration de sa durée de vie. Un CDN proposant une purge peut supprimer sa propre copie, mais cette purge n’atteint pas les copies déjà stockées dans les navigateurs. Servez ces fichiers avec no-cache et des validateurs afin que chaque réutilisation soit vérifiée et qu’un fichier inchangé ne coûte qu’une réponse 304.
Servir une réponse à partir d’un fichier la rend-il sûre pour un cache partagé ? Non. La possibilité de mise en cache dépend de la requête et des en-têtes de réponse, pas de la façon dont le corps a été produit. La RFC 9111 interdit à un cache partagé de réutiliser une réponse à une requête contenant Authorization, sauf si la réponse l’autorise avec public, s-maxage ou must-revalidate. Elle n’impose aucune règle de ce type pour une requête contenant un en-tête Cookie, et MDN précise qu’un cookie seul ne rend pas une réponse privée. La RFC indique également que Set-Cookie n’empêche pas la mise en cache. Un fichier statique envoyé avec un cookie peut donc être stocké et réutilisé pour des requêtes ultérieures par un cache conforme à la norme. Un CDN peut toutefois appliquer sa propre règle : comme indiqué plus haut, Cloudflare ne met pas une telle réponse en cache par défaut. Évitez de définir des cookies sur les chemins statiques. Lorsqu’une réponse doit en contenir un ou est personnalisée par un cookie, marquez-la private : un cache partagé tel qu’un CDN ne doit alors pas la stocker, de sorte que ce fichier n’est mis en cache que dans les navigateurs.
Qu’est-ce qui change lorsque les fichiers sont précompressés ? Les fichiers compressés et non compressés constituent deux représentations derrière une même URL. Les réponses ont donc besoin de Vary: Accept-Encoding, et la RFC 9110 précise qu’un ETag fort pour une représentation avec codage de contenu doit être distinct de celui de la représentation sans ce codage, afin d’éviter les conflits lors des mises à jour du cache et des requêtes par plages. Les serveurs ne prennent pas tous en charge ces aspects de la même façon. Le module gzip_static de nginx envoie un fichier .gz existant à la place du fichier normal, mais n’ajoute Vary: Accept-Encoding que lorsque gzip_vary est activé, ce qui n’est pas le cas par défaut. Aucune des deux pages des modules nginx ne précise comment le ETag d’une réponse .gz est formé. Demandez donc un fichier avec et sans Accept-Encoding: gzip, confirmez à l’aide de Content-Encoding que seule la première réponse est compressée, puis comparez les en-têtes Vary et ETag des deux réponses. Répétez la vérification via le CDN : gzip_static tient également compte de gzip_proxied, et sa valeur par défaut, off, désactive la compression pour les requêtes contenant un en-tête Via. Une requête transmise par un CDN peut donc recevoir le fichier non compressé. Le module mod_deflate d’Apache, qui compresse à la volée, ajoute par défaut la méthode de compression au ETag, et sa documentation indique que cela empêche les réponses 304 aux requêtes conditionnelles portant sur du contenu compressé.

Appliquez de longues durées de vie du cache lorsque chaque révision du contenu possède une URL unique, afin de réduire la latence et la charge sur l’origine. Une mise en cache plus courte ou une revalidation est plus sûre lorsqu’une URL stable peut recevoir des mises à jour.

Les fichiers qu’une Assembly exporte avec un Robot de stockage deviennent alors du contenu statique : ils restent dans votre bucket au chemin choisi, et votre stockage ou CDN les sert. Le Robot /s3/store accepte un objet headers qui est appliqué au fichier stocké, et /video/adaptive attribue à chaque segment et liste de lecture un relative_path afin que l’organisation des fichiers stockés corresponde aux références des listes de lecture. Le Smart CDN est l’équivalent à la demande : un résultat est généré lors de sa première demande, puis mis en cache. Le Robot /file/serve définit l’en-tête Cache-Control que reçoivent les navigateurs et le CDN, et cache_duration permet de le modifier.

Un lecteur dans le navigateur qui charge des fichiers HLS ou MPEG-DASH depuis une origine différente de celle de la page, comme le nom d’hôte d’un bucket ou d’un CDN, a besoin d’en-têtes CORS sur le serveur qui sert les fichiers ; la page /video/adaptive les répertorie. Une fois les fichiers exportés stockés, leurs en-têtes de cache relèvent de votre stockage ou de votre CDN.

Explorer les capacités de diffusion de Transloadit

Qu’est-ce que le contenu statique ?

Fonctionnement du contenu statique

Points clés

Quand le contenu statique est utile

Comment Transloadit vous aide à utiliser le contenu statique

Références

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