Cache-Control
Description
The Cache-Control
response header defines the caching policies for a resource. It specifies directives that control how and for how long a response can be cached by browsers, proxies, and other intermediary caches. This header is a key component of HTTP/1.1 caching mechanisms and provides granular control over caching behavior.
Using Cache-Control
effectively can significantly improve website performance by reducing server load and network traffic. It allows servers to specify whether a response can be cached, who can cache it, and how long it remains valid. Proper cache configuration reduces unnecessary requests to the server and ensures that users receive the most appropriate version of a resource.
Syntax
The syntax of the Cache-Control
header follows this structure:
<directive>
: A caching directive that specifies an aspect of the caching policy.- Multiple directives can be combined, separated by commas.
Common Directives
Response Directives
public
: Response can be cached by any cache.private
: Response is intended for a single user and must not be stored by shared caches.no-cache
: Response can be stored by caches but must be validated with the origin server before each reuse.no-store
: Response must not be stored in any cache.max-age=<seconds>
: Maximum time in seconds that the response is considered fresh.s-maxage=<seconds>
: Similar to max-age but applies only to shared caches.must-revalidate
: Cache must verify the status of stale resources before using them.proxy-revalidate
: Like must-revalidate, but only applies to shared caches.immutable
: Indicates that the response will not change during its freshness lifetime.stale-while-revalidate=<seconds>
: Allows stale response while revalidating in the background.stale-if-error=<seconds>
: Allows serving stale content if the server returns an error.
Example Syntax
This example indicates that the response is intended for a single user and can be cached for one hour.
Examples
Private Caching Example
A response that should only be cached by the user's browser:
HTTP/1.1 200 OK
Date: Mon, 02 Jun 2025 14:00:00 GMT
Content-Type: text/html
Cache-Control: private, max-age=3600
<!DOCTYPE html>
<html>
<head><title>User Profile</title></head>
<body>Welcome back, John!</body>
</html>
Public Caching Example
A response that can be cached by any intermediary:
HTTP/1.1 200 OK
Date: Mon, 02 Jun 2025 14:10:30 GMT
Content-Type: image/jpeg
Cache-Control: public, max-age=86400, immutable
Content-Length: 123456
[... image data ...]
This example allows the image to be cached publicly for 24 hours and indicates that it will not change during this period.
No Caching Example
A response that should not be cached at all:
HTTP/1.1 200 OK
Date: Mon, 02 Jun 2025 14:20:45 GMT
Content-Type: application/json
Cache-Control: no-store
Content-Length: 42
{"status": "success", "balance": "$1,250.00"}
Complex Caching Strategy
A response with a more sophisticated caching strategy:
HTTP/1.1 200 OK
Date: Mon, 02 Jun 2025 14:30:15 GMT
Content-Type: text/html
Cache-Control: public, max-age=3600, must-revalidate, stale-while-revalidate=60
ETag: "abc123"
Content-Length: 5432
<!DOCTYPE html>
<html>
<head><title>News Article</title></head>
<body>Latest news content...</body>
</html>
This example allows the response to be cached publicly for one hour, requires revalidation when stale, but allows the stale content to be used for up to 60 seconds while revalidation happens in the background.
Summary
The Cache-Control
response header is a powerful tool for optimizing web performance and reducing server load through effective caching strategies. By carefully selecting and combining directives, servers can implement sophisticated caching policies tailored to the specific requirements of different resources. Understanding and properly implementing Cache-Control
is essential for building efficient and responsive web applications.