Headers and directives related with Cache Control

Response Headers

1. Cache-Control

Specify directives for caching mechanisms in both of the Network layer cache(Edge Cache) and the browser cache.

• Default value: the default value of Cache-Control is 'public, max-age=0, must-revalidate' which instructs both the Edge Network and the browser not to cache
• Recommended setting of Vercel: Vercel recommended to set the Cache-Control as 'max-age=0, s-maxage=86400'(adjust s-maxage you want to). This configuration tells browsers not to cache, allowing Vercel's Edge Network to cache responses and invalidate them when deployment update.

1) Basic directives of Response

• max-age=N: indicate that the response remain fresh until N seconds after the response is generated.  
• s-maxage=N: indicate how long the response remain fresh in a shared cache. The s-maxage directive is ignored by private caches, and overrides the value specified by the max-age directive or the Expires header for shared cache.
• no-cache: Indicate that the response can be stored in caches, but the response must be validated with the origin server before each reuse, even when the cache is disconnected from the origin server.
• must-revalidate: Indicate that the response can be stored in caches and can be reused while fresh. If the response becomes stale, it must be validated with the origin server before reuse. Typically, it is used with max-age directive. HTTP allows caches to reuse stale responses when they are disconnected from origin server. must-revalidate is a way to prevent this from happening.
• proxy-revalidate: This is equivalent of must-revalidate, but specifically for shared cahces only.
• no-store: Indicate that any caches of any kind should not store this response
• private: Indicate that the response can be stored only in a private cache (e.g. local caches in browsers). It is used for user-personalized content, if you forget to add private to a response with personalized content, then that response can be stored in a shared cache.
• public: Indicated that the response can be stored in a shared cache. The response with Authorization header fields must not be stored in a shared cache
• must-understand: Indicate that a cache should store the response only if it understands the requirements for cacching based on status code
• no-transform: Indicate that any intermediary shouldn't transform the response contents.
• immutable: Indicate that the response will not be updated while it is fresh
• stale-while-revalidate=N: This diretive allows you to serve content from the Edge cache(shared cache) while simultaneously updating the cache in the background with the response from you function. This is useful when your content changes frequently, but regeneration is slow or want to have the flexibility to update it without waiting for the cache to expire
• stale-if-error: Indicate that the cache can reuse a statle response when an upstream server generates an error

2) Basic directives of Request

• no-cache: Ask caches to validate the response with the origin server before reuse. It allows client to request the most up-to-date response even if the cache has a fresh response.(Browsers usually add no-cache to requests when user are force reloading a page)
• no-store: Allow a client to request that caches refrain from storing the request and corresponding response, even if the origin server's response could be stored.
• max-age=N: Indicate that the client allows a stored response that is generated on the origin server within N seconds.
• max-stale=N: Indicate that the client allows a stored response that is stale within N seconds.
• min-fresh=N: Indicate that the client allows a stored response that i fresh for at least N seconds.
• no-transform: Same as no-transform for a response
• only-if-cached: Indicate that an already cached response should be returned

3) Which Cach-Control headers to use with CDNs?

• If you want to control caching similarly on Vercel, CDNs, and the client, use Cache-Control
• If you want to control caching on Vercel and also on other CDNs, use CDN-Cache-Control 
• If you want to control caching only on Vercel, use Vercel-CDN-Cache-Control
• If you want to specify different caching behaviors for Vercel, other CDNs, and the client, you can set all three headers

2. Pragma

When Vercel's Edge Network CDN receives a request with Pragma: no-cache (such as when the browser devtools are open), it will revalidate any stale resource synchronously, instead of in the background.

3. CDN-Cache-Control Header

The CDN-Cache-Control or Vercel-CDN-Cache-Control headers can be used to specify caching behavior on the Edge Network and/or CDNs.

• The priority order is like this [ Vercel-CDN-Cache-Control > CDN-Cache-Control > Cache-Control ].
• Vercel-CDN-Cache-Control: It controls caching behavior only within Vercel's Edge Cache.
• CDN-Cache-Control: It configures Vercel's Edge Cache and is used by other CDNs, allowing you to configure intermediary caches. If Vercel-CDN-Cache-Control is also set, this only influences other CDN caches.
• Cache-Control: Specify directives for caching mechanisms in bot of the Network layer cache(Edge Cache) and the browser cache.

2. x-vercel-cache

Indicate whether the response was served from Vercel's edge cache. The follwing values are possible when the content being served is static or a Cache-Control header.

• MISS: the response was not fount in the edge cache and was fetched from the origin server
• HIT: the response was served from the Edge Cache
• STALE: the response was served from the edge cache. a background request to the origin server was made to update the content
• PRERENDER: the response was served from static storage
• REVALIDATED: the response was served from the origin server and the cache was refresed due to an authorization from the user in the incoming request