1. Home
2. Guides
3. Full-Site Delivery
4. Caching

You can use cache control headers in your origin's responses to set policies that determine the maximum amount of time that content may be cached by Fastly. Fastly looks for caching information in each of these headers as described in our documentation on cache freshness in order of preference:

1. Surrogate-Control:
2. Cache-Control: s-maxage
3. Cache-Control: max-age
4. Expires:

Surrogate headers

Surrogate headers provide a specific cache policy for CDN caches like Fastly. Surrogate-Control accepts many of the same values as Cache-Control, plus some other more esoteric ones.

One use of this technique is to provide conservative cache interactions to the browser (for example, Cache-Control: no-cache). This causes the browser to re-validate with Fastly on every request for the content, ensuring users get the freshest possible content. Simultaneously, your origin can send a Surrogate-Control header with a longer max-age that lets Fastly handle most of the browser traffic, only passing requests to your origin when Fastly's cache expires.

With Fastly, one of the most useful Surrogate headers is Surrogate-Key. When Fastly processes a request and sees a Surrogate-Key header in your origin's response, it uses the space-separated value as a list of tags to associate with the request URL in the cache. Combined with Fastly's Purge API, an entire collection of URLs can be expired from the cache in one API call (and typically happens in around 1ms).

Cache-Control directives

Only the following Cache-Control response directives, as defined by section 5.2.2 of RFC 9111, influence Fastly's caching:

• Cache-Control: public - Any cache can store a copy of the content. You don't need to add the public directive to a response as most content is cacheable by default.
• Cache-Control: private - Don't store. This is intended for user-specific content.
• Cache-Control: max-age=[seconds] - Caches can store this content for n seconds.
• Cache-Control: s-maxage=[seconds] - Same as max-age but applies specifically to CDN caches like Fastly.

All other Cache-Control directives are ignored and will not influence Fastly's caching, but will be passed through to the browser. Directives ignored by Fastly include, but are not limited to, Cache-Control: no-cache, Cache-Control: no-store, and Cache-Control: must-revalidate.

For more in-depth information about how Fastly responds to cache control headers and how these headers interact with Expires and Surrogate-Control, check out our documentation on HTTP caching semantics.

Authorization header

Requests with an Authorization header are considered cacheable by default. To prevent requests with an Authorization header from receiving a cached response, refer to the documentation on HTTP caching semantics.

Expires header

The Expires header tells caches how long to store a piece of content. The downside is that it's a static date, and if your origin doesn't update it, the date will pass and browsers will start requesting that resource from Fastly every time.

Fastly will respect the Expires header value only if your origin doesn't send Surrogate-Control or Cache-Control headers in the response.