Storing reusable copies of resources or responses to reduce repeated processing and delivery time.
Caching stores a response or resource so it can be reused instead of fetched or generated again for every request. A browser can keep its own copies, and shared infrastructure can reuse eligible responses across visitors. The correct policy depends on what the resource contains and how it changes.
Freshness and correctness are central to that policy. A cached logo may remain useful for a long time; an account page or changing availability information needs a different approach. Caches can expire or validate stored responses, but the site must communicate and implement the intended behavior.
Do not treat all caching layers as one switch. Browser caching, a hosting page cache and a CDN can each affect what a visitor receives. An editor may see an updated page while an anonymous visitor still receives an older copy from another layer. Identify the response path before repeatedly changing the content.
Takeaway: Use caching where reuse is appropriate, and keep a clear update process. Test anonymous and personalized experiences separately so efficiency does not come at the expense of accuracy or privacy.
Example
A store corrects a public returns-policy page. The editor sees the new text, but a visitor still receives a cached version. The team checks which layer served the old response and uses the supported update or invalidation process. Disabling every cache permanently would be a broad response to a specific freshness problem.
What to check
Sensitive or user-specific responses must not be reused across users by an incorrectly configured shared cache. Review the relevant headers and application rules with the developer. Record exactly which cache was changed, and verify the final response rather than assuming a purge button proves the outcome.
For more detail, see HTTP caching.