What is Caching Images?
Caching images stores fetched or generated image responses so that later requests can reuse them, usually in a browser or at a CDN edge close to the viewer. A repeated request then avoids the origin transfer or the transformation work for as long as the entry has not been evicted or invalidated and its freshness policy still allows reuse.
How Caching Images works
Image caching can occur in a browser, application, transformation service, CDN, or several tiers at once. The reusable object may be an original file or a derived rendition selected by dimensions, crop, density, quality, and negotiated format. A well-defined key and freshness policy lets identical transformation requests converge on one result, while validation or invalidation reconnects that result to changes in the source asset.
Key facts
- 1What belongs in the cache key? Every request value that changes the response, and none that does not. For a transformation endpoint that is at least every input that changes the output bytes: omitting crop mode, focal point, orientation, or quality can return a valid but wrong rendition, while including values that do not affect the response stores duplicates and lowers the hit ratio. Check where your parameters travel, because CDN defaults differ: Amazon CloudFront’s default cache key is the distribution’s domain name and the URL path, so
?w=300and?w=600share one cached object until a cache policy adds the query string; Cloudflare’s default key includes the full query string; Google Cloud CDN backend buckets by default include only query parameters known to Cloud Storage, with others added through an include list. - 2Format negotiation on
Acceptneeds every cache to split on it. If one URL returns AVIF, WebP, or JPEG depending on the request’sAcceptheader, sendVary: Acceptso that each cache on the path knows the response depends on that header, and confirm that your CDN really keeps the formats apart, through itsVaryhandling or an explicit format key; otherwise a cache can hand a client an encoding that was chosen for a different client. A CDN-side key alone tells caches downstream of the CDN nothing. Support is uneven. Cloudflare does not considerVaryby default except forAccept-Encodingand offers a separate Vary for Images setting. Google Cloud CDN honorsVary: Acceptand keeps a separate entry per distinctAcceptvalue, but does not allowAcceptas a configured cache key header because it has so many values. Putting the format in the URL avoids the dependency; the browser can then choose, for example among the sources of apictureelement that each declare atype. - 3Replacing an original under the same path does not change the URL of any derivative, so each cache that holds one can keep serving it until the entry is purged, or expires and is revalidated; a stale-serving policy such as
stale-while-revalidatestretches that further. Whether purging the original also removes its variants depends on the provider: Fastly Image Optimizer purges the original and all variants in one request, and Cloudflare’s image transformations purge an image’s optimized versions when the original’s URL is purged, and not individually. Where derivatives are cached as independent URLs with no such link, use the tag, prefix, or explicit-URL purge the provider supports. A CDN purge does not reach browser caches. A new derivative URL sidesteps every cache, the browser’s included: put a version or content hash of the source in the path, or in a query parameter that is part of the cache key, and have pages reference the new URL. If the transformation layer also caches the original, as Cloudflare’s does, purge or version the source too, or the new derivative can be built from the old image. - 4A cached variant is not a stored file. A browser cache only serves the same user again, so a transformation service that keeps no copy of its output relies on a shared cache in front of it, typically a CDN, to spare other viewers the work. A CDN can evict an entry before it expires to make room for other content, and each edge location fills its own cache, so the origin or transformation service must be able to produce any variant again at any time and the original has to stay available. A request that no cache tier can answer pays the fetch and transformation cost again, and every variant is a separate entry: Cloudflare, for example, caches each unique combination of source image and parameters separately. An upstream tier can soften this where the CDN has one; Fastly Image Optimizer caches the transformed image at its shield as well as at the edge.
When Caching Images matters
Cache transformed variants to reduce latency, processing load, and bandwidth use for repeated dimensions and formats. Include transformation inputs in the key or one variant may be served for another request.
How Transloadit helps with Caching Images
Transloadit’s Smart CDN is an image transformation layer with this caching built in. A tlcdn.com URL names the Workspace, the Template, the source file path, and the transformation parameters. On a cache miss the Template’s Assembly runs and the result is cached; on a hit the edge answers without running it again. Each parameter selection is a different URL and therefore a separate cached rendition, and the /file/serve Robot sets how long browsers and the CDN keep a result.
Smart CDN is documented as a transformation and delivery layer, not as storage: keep the originals in your own storage. The linked pages do not describe a purge operation or what happens to a cached result when an original is replaced under an unchanged path; test that case on your own Workspace before relying on it.
Sources
- RFC 9111, Section 4.1: Calculating Cache Keys with the Vary Header Field
- MDN: Vary header reference
- Amazon CloudFront: Understand the cache key
- Cloudflare: Cache keys (default key and custom keys)
- Cloudflare: Serving tailored content (Vary for Images)
- Google Cloud CDN: Caching overview (cache keys, Vary headers, stale content, eviction)
- Fastly Image Optimizer reference: shield caching and purging images with their variants
- Cloudflare Images: caching and purging optimized images
- MDN: HTTP caching (cache busting for images and other subresources)
- MDN: The picture element (the type attribute on its sources)