What is the Cache-Control Header?
Cache-Control is an HTTP request or response header whose directives govern storage, freshness, revalidation, and reuse by caches. Different directives can apply to browsers and shared intermediaries.
How the Cache-Control Header works
Cache-Control communicates policy through composable directives attached to an HTTP request or response. Freshness directives determine when reuse can occur without contacting the origin, while storage, validation, and scope directives constrain what private and shared caches may retain or serve. In media delivery it is set differently for versioned objects, mutable manifests, authenticated responses, and error responses rather than applied as one site-wide value.
Key facts
- 1
no-cacheallows a response to be stored but requires successful validation before reuse;no-storeinstructs caches not to retain the response in the first place. - 2
max-agesupplies a freshness lifetime for caches generally, whiles-maxagecan override that lifetime in shared caches without changing the browser’s private-cache lifetime. - 3
privateprevents storage by shared caches but permits a private cache. It is therefore different from disabling caching and is relevant to personalized media or entitlement responses.
When the Cache-Control Header matters
Set Cache-Control according to whether a response is public, private, immutable, or frequently updated. Conflicting or overly permissive directives can expose private data or preserve stale media.
Common use cases for delivery
These examples cover delivery broadly, not specifically the Cache-Control Header.
- Serving image, audio, video, and document derivatives to a geographically distributed audience.
- Protecting private assets worldwide with expiring or signed requests.
- Reducing repeated processing and origin traffic by caching deterministic results.
Working with delivery
This guidance covers delivery broadly, not just the Cache-Control Header.
A client requests an asset using a URL or playback manifest. A delivery layer evaluates authorization and cache state, serves a cached response when possible, or retrieves the asset from its origin before forwarding and optionally caching it.
Delivery choices determine more than download speed. Cache keys, origin behavior, authorization, geographic routing, invalidation, and egress cost decide whether an asset is fast, current, and available to the right audience.
What you gain
- Edge caching places frequently requested assets closer to viewers.
- Explicit cache and authorization rules reduce avoidable origin work.
- Multiple delivery variants let clients request an asset suited to their context.
What it costs
- Long cache lifetimes improve hit ratio but make replacement and invalidation more difficult.
- Signed access protects private media but adds key management, clock, and cache-partitioning concerns.
- More variants improve client fit while increasing storage, cache fragmentation, and operational complexity.
Before production
- 1Define cache keys, cache lifetime, invalidation, and authorization behavior explicitly.
- 2Measure time to first byte, cache-hit ratio, egress, and behavior after an origin failure.
- 3Test signed and unsigned requests at the CDN edge, not only against the origin.