Transloadit

What is CDN Caching?

CDN caching stores copies of content at geographically distributed edge locations. Requests can be served near their recipients without repeatedly retrieving the same representation from the origin.

How CDN Caching works

A CDN maps a request to an edge location and attempts to reuse an object stored there or in an intermediate shield. On a miss, the network retrieves the representation from an upstream cache or origin, then stores it according to freshness and eligibility rules. Each location fills its own cache, so an object that is warm in one region can still be a miss in another, and an unpopular object can be evicted before it expires. For media, immutable segments and derivatives can receive long lifetimes, while manifests and authorization-dependent responses usually need shorter or more selective treatment.

Key facts

  1. A stream’s manifest and its media segments need different lifetimes. In HLS, a live media playlist is replaced by a new version with at least one new segment about once per target duration (RFC 8216 requires it no sooner than half and no later than one and a half times that duration), so an edge that keeps the playlist longer hides new segments from players. A playlist marked VOD must not change and can be cached like a static file. Segments are fetched separately from the playlist, each under its own URL or as a byte range of a larger file, and can take long lifetimes provided the packager never changes the bytes behind a published URL, which the specification does not itself guarantee. Apple’s draft second edition of HLS recommends, in its low-latency server profile, caching ordinary playlist responses for half the target duration and using Cache-Control to communicate the lifetime.
  2. The cache key decides which requests share an entry, and its default differs by CDN. Amazon CloudFront’s default key is the distribution’s domain name and the URL path, without query strings, headers, or cookies. Cloudflare’s default includes the scheme, host, and path with query string, plus the request’s Origin header, so the same URL fetched with and without Origin is stored separately. Google Cloud CDN uses the complete request URI for backend services. Requests share an entry whenever their keys are identical, which a default can already cause: under CloudFront’s default, URLs that differ only in the query string receive the same cached response. Put every request value that changes the response into the key and leave out the rest, because a component that varies between requests without changing the response splits the cache and lowers the hit ratio.
  3. For large files, find out how the CDN handles Range requests, because it changes origin load and seek behavior. CloudFront forwards a range it does not hold to the origin, possibly asking for a larger range, and caches the returned part; if the origin does not support ranges, CloudFront receives and caches the entire object. Google Cloud CDN fills its cache with its own byte range requests once it has recorded that the origin supports them, which requires Accept-Ranges: bytes, a known total length, and both Last-Modified and a strong ETag, and it applies a much lower maximum cacheable size when the origin lacks that support. Fastly caches large objects in parts only when Segmented Caching is enabled. An origin that answers range requests correctly is therefore a precondition for caching large media in parts.
  4. Whether a response is eligible for caching is decided separately from how long it stays fresh, and the rule is provider-specific. Cloudflare caches by file extension by default and does not cache HTML or JSON without a rule. Google Cloud CDN’s default mode caches static content types by Content-Type and needs explicit directives for HTML and JSON. A response that sets a cookie is not cached by Google Cloud CDN; Cloudflare, depending on its configuration, either leaves it uncached or removes the cookie and caches it. When an expected hit does not happen, read the cache status the CDN reports: on Cloudflare, the CF-Cache-Status response header shows MISS when the response was eligible but not in that cache, BYPASS when the origin response was not cacheable, and DYNAMIC when the request was never eligible.

When CDN Caching matters

Configure CDN caching to lower media latency, reduce origin load, and absorb traffic spikes. Poor cache keys or freshness rules can serve incorrect variants or leave users with stale content.

How Transloadit helps with CDN Caching

Transloadit’s Smart CDN puts a CDN cache in front of on-demand processing. Requests to a tlcdn.com URL are delivered by the /tlcdn/deliver Robot, which caches results and serves them from edge locations. On a cache miss the Template’s Assembly runs; on a hit the edge answers without running anything. The Cache-Control values sent by the /file/serve Robot set how long a cached result stays fresh.

The first uncached request for a URL includes source fetching and processing time. Current default lifetimes are listed on the /file/serve page and are not repeated here because they can change.

Explore Transloadit’s delivery capabilities

Sources

Turn media knowledge into a working pipeline

Connect uploads, processing, AI, storage, and delivery through one declarative API — with the encoding stack, scaling, and format churn handled for you.

Try Transloadit for free