Cache-Control HTTP header plays a critical role in determining how, and for how long, individual responses can be cached by a browser or other caching system. It provides a mechanism for controlling resources in the client cache and intermediate caches.
When a web page or other resource is requested by a client (usually a browser), the server responds not only with the requested resource but also with metadata about the resource, contained in HTTP headers. One of these headers is
Cache-Control header is part of the HTTP specification and defines how a resource is cached. This can significantly affect the performance and load of a web server, making understanding this header crucial for efficient web development and administration.
Cache-Control header fields consist of directives which determine how a resource is cached. Multiple directives are separated by a comma.
For instance, this is what a typical
Cache-Control header might look like in an HTTP response:
Cache-Control: max-age=3600, must-revalidate
The example shows two directives:
max-age=3600, which means the resource is valid for 3600 seconds, and
must-revalidate, indicating the cache has to verify the status of the stale resources before using it and should re-fetch from the origin server if necessary.
The Cache-Control directives are the essential part of this header. They give instructions to the browser and caching systems about how to handle the resource. There are several directives, and each of them has a unique purpose.
public: This directive indicates that the response can be cached by any cache, even if the response would normally be non-cacheable or cacheable only within a private cache.
private: This response is specific to a single user and must not be stored by a shared cache. A private cache (like the user’s browser) may store it.
no-cache: The response can be cached, but must be revalidated with the server on each request before being served from the cache.
no-store: No part of the request or response should be stored by a cache. It instructs the cache to always fetch a fresh copy of the resource from the server.
max-age=[seconds]: The maximum amount of time that a resource will be considered fresh. This freshness lifetime is calculated relative to the time of the request.
s-maxage=[seconds]: Similar to
max-age, but it only applies to shared caches (e.g., proxies) and is ignored by a private cache.
max-stale=[seconds]: Indicates the client is willing to accept a stale response. An optional number of seconds can be given.
min-fresh=[seconds]: Indicates the client wants a response that will still be fresh for at least the specified number of seconds.
Revalidation and Reload Directives
must-revalidate: The cache must verify the status of the stale resources before using it and should re-fetch from the origin server if necessary.
proxy-revalidate: Similar to
must-revalidate, but it only applies to shared caches.
no-transform: This directive forbids a proxy or browser to modify the resource during a ‘save’ operation or when it’s served from cache.
The following examples show how the
Cache-Control header can be used in an HTTP response:
Caching a Resource for a Specific Time
If you want a resource to be cached for 24 hours, use the
max-age directive. Here’s what it would look like in the HTTP response:
Disabling Caching for a Resource
If you want a resource never to be cached, use the
no-store directive. Here’s what the HTTP response header would look like:
Cache-Control HTTP header is a tool for controlling how your web resources are cached. By understanding the various directives, you can tailor the caching behavior to suit your application’s requirements, which can lead to improved performance and reduced server load. It’s a critical aspect of HTTP that every web developer should understand. Remember, intelligent caching can make a substantial difference in the load time of your pages and the overall user experience.