Caching with the right rules
Which responses may be reused, by whom, for how long and how to confirm that the stored copy is still valid.
Reusing a response avoids repeated work
A response already available close to the visitor saves transfer, processing and waiting time. A browser can keep a private copy for the same person. An intermediary can keep a shared copy for many people. Both layers reduce work, but their responsibilities are different.
A private cache may store content associated with one user when policy allows it. A shared cache needs to be more conservative because a response intended for one person must never be shown to another. The strategy therefore starts by classifying the response: public or personal, stable or volatile.
The cache key decides whether requests are equivalent
Every cache selects a response through a key. The requested address is usually part of it, but the method, headers and intermediary rules may also matter. If a page varies by language, encoding or another attribute, that variation has to be represented in a controlled way.
The Vary header identifies request fields used to select a representation. Each declared variation expands the stored object set and lowers the chance of a hit. Varying a page by many cookies or headers can make a shared cache almost useless.
Fresh, stale and validated are different states
A fresh response can be reused without contacting the origin. When freshness ends, the complete content does not always need to be downloaded again. Validators such as ETag and Last-Modified allow a client to ask whether the representation is unchanged; a short response can then confirm the existing copy.
This distinction avoids two extremes: contacting the origin on every visit or serving old content without control. Cache-Control directives express the policy, including freshness lifetime, private storage, prohibition of storage and mandatory revalidation.
Versioned resources can remain fresh for longer
Style sheets, scripts, fonts and images can use addresses that change whenever their content changes. Under this model, the old address continues to identify the old file, while new content receives a new address. The resource can stay cached for a long time without blocking an update.
That contract must be real: the same versioned address should not begin serving different bytes. Otherwise, browsers and points of presence start holding incompatible variants. The version belongs to the identity of the resource.
HTML and personalized data need another policy
Documents can change frequently and may contain session data, permissions or preferences. A public page might allow a short lifetime or revalidation. An authenticated response often requires a private cache or a ban on shared storage, depending on the content and risk.
Beyond old content there is the risk of leaking: an incomplete key or a personalized response marked as public reaches the wrong user. Security and correctness come before hit rate.
Invalidation belongs in the design
Every strategy needs to explain how an urgent correction reaches the public. Versioned addresses avoid invalidating static resources. For content that stays at the same address, short expiration, revalidation or selective removal may be more appropriate.
Operations observe hits, misses, response age and origin behavior. A high hit rate with the wrong key only distributes one person response to another faster. A useful result combines lower origin load, predictable updates and the correct content for every request.