Qu’est-ce que la mise en cache d’images ?

La mise en cache d’images stocke les réponses contenant des images récupérées ou générées afin que les requêtes ultérieures puissent les réutiliser, généralement dans un navigateur ou en périphérie d’un CDN proche de l’utilisateur. Une requête répétée évite alors le transfert depuis le serveur d’origine ou le travail de transformation tant que l’entrée n’a pas été évincée ou invalidée et que sa politique de fraîcheur autorise encore sa réutilisation.

La mise en cache d’images peut intervenir dans un navigateur, une application, un service de transformation, un CDN ou plusieurs niveaux à la fois. L’objet réutilisable peut être un fichier original ou une variante dérivée sélectionnée selon les dimensions, le recadrage, la densité, la qualité et le format négocié. Une clé et une politique de fraîcheur bien définies permettent à des requêtes de transformation identiques de converger vers un seul résultat, tandis que la validation ou l’invalidation rétablit le lien entre ce résultat et les modifications de la ressource source.

Quelles valeurs doivent figurer dans la clé de cache ? Toutes les valeurs de requête qui modifient la réponse, et aucune autre. Pour un point de terminaison de transformation, cela comprend au moins chaque donnée d’entrée qui modifie les octets de sortie : omettre le mode de recadrage, le point focal, l’orientation ou la qualité peut renvoyer une variante valide mais incorrecte, tandis qu’inclure des valeurs sans effet sur la réponse stocke des doublons et réduit le taux de succès du cache. Vérifiez où vos paramètres sont transmis, car les réglages par défaut des CDN diffèrent : la clé de cache par défaut d’Amazon CloudFront se compose du nom de domaine de la distribution et du chemin de l’URL. Ainsi, ?w=300 et ?w=600 partagent un même objet en cache tant qu’une politique de cache n’ajoute pas la chaîne de requête. La clé par défaut de Cloudflare inclut la chaîne de requête complète. Les buckets backend de Google Cloud CDN n’incluent par défaut que les paramètres de requête connus de Cloud Storage, les autres étant ajoutés au moyen d’une liste d’inclusion.
La négociation de format fondée sur Accept exige que chaque cache distingue ses entrées selon cette valeur. Si une URL renvoie du contenu AVIF, WebP ou JPEG selon l’en-tête Accept de la requête, envoyez Vary: Accept pour que chaque cache sur le trajet sache que la réponse dépend de cet en-tête. Vérifiez aussi que votre CDN sépare réellement les formats, par sa gestion de Vary ou par une clé de format explicite ; sinon, un cache peut fournir à un client un encodage choisi pour un autre client. Une clé définie uniquement côté CDN n’informe pas les caches situés en aval du CDN. La prise en charge varie. Cloudflare ne tient pas compte de Vary par défaut, sauf pour Accept-Encoding, et propose un réglage distinct nommé Vary for Images. Google Cloud CDN respecte Vary: Accept et conserve une entrée séparée pour chaque valeur distincte de Accept, mais n’autorise pas l’utilisation de Accept comme en-tête configuré dans la clé de cache, car cet en-tête prend un très grand nombre de valeurs. Placer le format dans l’URL évite cette dépendance ; le navigateur peut alors choisir, par exemple parmi les sources d’un élément picture qui déclarent chacune un attribut type.
Remplacer un original au même chemin ne modifie l’URL d’aucune variante dérivée. Chaque cache qui en contient une peut donc continuer à la diffuser jusqu’à la purge de l’entrée, ou jusqu’à son expiration suivie d’une revalidation ; une politique de diffusion de contenu périmé telle que stale-while-revalidate prolonge encore cette période. La suppression des variantes lors de la purge de l’original dépend du fournisseur : Fastly Image Optimizer purge l’original et toutes ses variantes en une seule requête, et les transformations d’images de Cloudflare purgent les versions optimisées d’une image lorsque l’URL de l’original est purgée, et non individuellement. Lorsque les variantes dérivées sont mises en cache sous des URL indépendantes sans un tel lien, utilisez la purge par balise, par préfixe ou par URL explicite prise en charge par le fournisseur. Une purge du CDN n’atteint pas les caches des navigateurs. Une nouvelle URL de variante dérivée contourne tous les caches, y compris celui du navigateur : placez une version ou une empreinte du contenu source dans le chemin, ou dans un paramètre de requête faisant partie de la clé de cache, et faites en sorte que les pages utilisent la nouvelle URL. Si la couche de transformation met aussi l’original en cache, comme le fait celle de Cloudflare, purgez ou versionnez également la source ; sinon, la nouvelle variante dérivée peut être produite à partir de l’ancienne image.
Une variante en cache n’est pas un fichier stocké. Le cache d’un navigateur ne sert à nouveau que le même utilisateur. Un service de transformation qui ne conserve aucune copie de sa sortie dépend donc d’un cache partagé placé devant lui, généralement un CDN, pour éviter de refaire le travail pour les autres utilisateurs. Un CDN peut évincer une entrée avant son expiration pour libérer de la place pour d’autres contenus, et chaque site de périphérie remplit son propre cache. Le serveur d’origine ou le service de transformation doit donc pouvoir produire à nouveau n’importe quelle variante à tout moment, et l’original doit rester disponible. Une requête à laquelle aucun niveau de cache ne peut répondre entraîne de nouveau le coût de récupération et de transformation, et chaque variante constitue une entrée distincte : Cloudflare, par exemple, met en cache séparément chaque combinaison unique d’image source et de paramètres. Un niveau en amont peut atténuer cet effet lorsque le CDN en dispose ; Fastly Image Optimizer met l’image transformée en cache dans son cache de protection ainsi qu’en périphérie.

Mettez les variantes transformées en cache pour réduire la latence, la charge de traitement et la consommation de bande passante lorsque les mêmes dimensions et formats sont demandés à nouveau. Incluez les données d’entrée de la transformation dans la clé ; sinon, une variante peut être diffusée en réponse à une autre requête.

Le Smart CDN de Transloadit est une couche de transformation d’images qui intègre cette mise en cache. Une URL tlcdn.com désigne le Workspace, le Template, le chemin du fichier source et les paramètres de transformation. Si le résultat est absent du cache, l’Assembly du Template s’exécute et le résultat est mis en cache ; s’il est présent, le cache de périphérie répond sans exécuter à nouveau l’Assembly. Chaque sélection de paramètres correspond à une URL différente et donc à une variante distincte en cache, et le Robot /file/serve définit la durée de conservation d’un résultat par les navigateurs et le CDN.

Le Smart CDN est documenté comme une couche de transformation et de diffusion, et non comme un stockage : conservez les originaux dans votre propre stockage. Les pages liées ne décrivent ni opération de purge ni ce qui arrive à un résultat en cache lorsqu’un original est remplacé sans changement de chemin ; testez ce cas dans votre propre Workspace avant de vous y fier.

Explorer les capacités de diffusion de Transloadit

Qu’est-ce que la mise en cache d’images ?

Fonctionnement de la mise en cache d’images

Points clés

Quand la mise en cache d’images est importante

Comment Transloadit vous aide à mettre les images en cache

Références

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