A proxy cache stores an eligible response and reuses it for later requests. Done well, this reduces origin work and network latency. Done badly, it can serve stale information or one user's private response to another.
Freshness and revalidation
Cache-Control directives describe whether a response may be stored and for how long. Validators such as ETag allow a cache to ask whether its copy is still current.
The cache key matters
A shared cache must vary on every request property that changes the representation. Missing language, encoding or authorization differences can produce incorrect content.
Protect private responses
Do not cache personalized dashboards, password resets or authenticated data in a public cache unless the design explicitly isolates users. Test logout and account switching.
Measure before expanding
Track hit ratio, age, origin load and purge behavior. Cache stable public assets first; add dynamic content only with documented invalidation.
Purge is part of publishing
Teams need a tested way to invalidate an incorrect or sensitive response quickly. Versioned asset filenames reduce purge needs, while editorial pages may require targeted URL invalidation.
Observe the decision
Expose safe cache-status headers and inspect Age, Vary and Cache-Control during tests. A fast response is not necessarily a correct cache hit, and a miss is not automatically a performance failure.
Cache only responses whose rules you understand
Public static assets are good candidates. Personalized pages, authenticated responses, shopping carts and private API data require careful Cache-Control, Vary and cookie handling. A cache key that ignores authorization or language can serve one user's result to another.
Validate correctness before celebrating speed
Inspect Age, Cache-Control, Vary and a safe cache-status header across a hit, miss, revalidation and purge. Change the resource and confirm that users receive the intended version. Versioned filenames simplify static deployments; editorial fixes may require targeted invalidation.
Cache performance is a measured trade-off among freshness, origin load and latency. “Cache everything” is not a production strategy.
Build the cache key from representation differences
A safe key may need the host, path, query, content encoding, language and other headers named by Vary. Authorization and cookies require particular care. If the key ignores a value that changes the response, one user's content can be served to another.
Public versioned assets are strong candidates. Authenticated pages, shopping carts and private API responses should not be cached unless the design explicitly supports it. Respect Cache-Control and avoid treating every successful GET as public.
Test freshness as well as speed
Inspect Age, Cache-Control, ETag and a safe cache-status header across a miss, hit, revalidation and purge. Change the resource and confirm that visitors receive the intended version. A fast stale response is a correctness failure.
Keep a tested invalidation path for urgent editorial and security changes. Versioned filenames reduce static-asset purges, while documents may need targeted invalidation. Measure origin load and latency before expanding rules, then monitor hit ratio alongside error and staleness reports.
Test requests with and without cookies, authorization and language headers. Serious cache failures often appear only when two users should receive different representations of the same URL.