/ HTTP Headers

Cache-Control

The 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.

Core Concept

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.

The 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.

The 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.

Understanding Directives

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.

Cacheability Directives

  • 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.

Expiration Directives

  • 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.

Practical Examples

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:

Cache-Control: max-age=86400

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: no-store

Summary

The 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.

Was this helpful?

Thanks for your feedback!