Transloadit

What is Content Caching?

Content caching stores reusable copies of responses, metadata, or generated assets near later consumers. Subsequent requests can avoid repeated computation or retrieval from the origin.

How Content Caching works

An HTTP cache stores a response under a cache key. The key is at least the request method and URL, and it can be extended by request headers that the response names in Vary or by CDN configuration. While a stored response is fresh, the cache can answer from it without contacting the origin. Once it is stale, the cache normally checks with the origin before using it again, unless a directive or the cache’s configuration permits serving the stale copy. When the origin sent a validator (ETag or Last-Modified), that check is a conditional request, and a 304 Not Modified answer lets the cache keep using the copy without downloading the body again. Two kinds of cache follow different rules. A private cache, typically the browser’s, belongs to one user and may hold personalized responses. A shared cache sits between clients and the origin and serves many users; CDNs and reverse proxies are shared caches run by the site operator, which MDN calls managed caches. Cache-Control sets an explicit lifetime with max-age and can address the two kinds separately: private tells shared caches not to store a response, and s-maxage overrides max-age for shared caches only. A managed cache adds its own configuration and purge operations on top. A purge removes the copy at the CDN, but copies already held by browsers stay until they expire. That is why assets that never change are published under versioned URLs with long lifetimes, while URLs that must stay stable are revalidated.

Key facts

  1. no-cache or no-store? no-store tells every cache, private or shared, not to keep the response. no-cache allows the response to be stored but forbids reusing it without first revalidating with the origin. When the response carries a validator such as ETag or Last-Modified and the origin answers conditional requests, an unchanged resource costs a small 304 Not Modified exchange instead of a full download; without them, a reuse normally means downloading the full response again. Neither directive guarantees privacy on its own: no-cache still permits storage, and RFC 9111 states that no-store is not a reliable or sufficient mechanism for ensuring privacy. A CDN can also treat no-cache differently from the RFC. Cloudflare documents that with its Origin Cache Control feature disabled it does not cache a no-cache response at all, and with the feature enabled it caches the response and always revalidates.
  2. Is a response without Cache-Control left uncached? Not reliably. When no explicit lifetime is given, RFC 9111 allows a cache to estimate one, typically as a fraction of the time since Last-Modified (the RFC’s example is 10%), and encourages origins to send explicit directives if they want to prevent caching. CDNs add defaults of their own. Cloudflare decides by file extension, not MIME type: it caches a 200 response for an extension on its default list, such as JPG, PNG, CSS, or JS, for a default period even when the response carries neither Cache-Control nor Expires, and it does not cache HTML or JSON unless a rule enables it. That default follows the URL’s extension, and a cache rule can extend it to everything, so do not rely on it to keep personalized pages out of the cache. Send an explicit policy on every response and read the CDN’s default behavior before relying on either.
  3. How do personalized responses stay out of a shared cache? Send Cache-Control: private, which tells shared caches such as CDNs not to store the response while still allowing the user’s browser to; for pages personalized after login MDN recommends Cache-Control: no-cache, private, so the browser also revalidates before reuse. HTTP protects only one case automatically: a shared cache must not reuse a response to a request that carried Authorization unless the response opts in with public, s-maxage, or must-revalidate. A response personalized through a cookie gets no such protection, and MDN notes that a cookie alone does not make a response private. A CDN honors the directive only while it follows origin headers: Cloudflare, for example, documents that it respects the origin’s cache headers unless an Edge Cache TTL cache rule overrides them, so check the CDN rules that match personalized URLs. private only controls where a response may be stored; RFC 9111 says it cannot ensure the privacy of the content.
  4. What has to be in the cache key for media variants? Every input that changes the output, and nothing else. When the variant depends on a request header, for example an image format negotiated through Accept, the response must list that header in Vary; under RFC 9111 a cache may then reuse a stored response only for requests whose listed headers match. A CDN does not necessarily apply that rule by default: Cloudflare documents that it does not consider Vary in caching decisions, except for Vary: Accept-Encoding, unless its Vary cache rule setting or Vary for images is configured. Confirm that the CDN varies its cache on the header before relying on Vary alone. When the variant depends on URL parameters such as width, crop, or format, those parameters must stay in the key, and CDN defaults differ here too: Cloudflare’s default cache key includes the query string, while Amazon CloudFront does not cache based on query string parameters when it is not configured to forward query strings to the origin. A key that omits an input serves one requester another’s derivative. A key with more than it needs stores duplicates: CloudFront advises caching only on parameters for which the origin returns different versions, and notes that it treats differently cased or ordered query strings as separate objects.

When Content Caching matters

Cache frequently requested media and variants when lower latency and reduced origin load outweigh freshness requirements. Incorrect keys or invalidation rules can serve stale, private, or mismatched content.

How Transloadit helps with Content Caching

Transloadit’s Smart CDN caches the output of a Template at the edge. On a cache miss it imports the original from your storage and runs the Assembly; later requests for the same URL are answered from the cached copy without running it again. The transformation parameters are part of the URL, so each combination is requested and cached as its own rendition.

The first request for each new URL includes the time to fetch and process the original. For signed Smart CDN URLs, the effective cache lifetime of a response is bounded by the remaining signature lifetime, so a short expiry also shortens how long a result is reused.

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