Why HTTP caching matters

A cache stores a response so a later request can reuse it without downloading the full body again. That is one of the biggest performance wins on the Web, and it is built into HTTP itself.

Browsers keep a private cache for one user. CDNs and proxies run shared caches that many users hit. Your origin server may also cache application work in memory or Redis, but HTTP caching specifically concerns reusable responses that any compliant cache can store.

Caching makes a site faster. It cuts bandwidth and reduces load on your server. Done wrong, it can serve stale content or leak private data to the wrong visitor. Every cache decision comes down to two questions:

1. May this response be stored?
2. May the stored copy be reused right now?

Cache-Control answers much of the first question. Validators such as ETag let a stale cache ask the origin whether its stored copy still matches the current resource.

Let’s see a cache hit in the terminal. Run the same request twice:

curl -I https://flaviocopes.com/img/og.png
curl -I https://flaviocopes.com/img/og.png

Read the cache-control header on the first response. On the second run, curl may reuse its connection, but the real proof is in the browser: open the Network panel, reload twice, and look for (disk cache) or (memory cache) in the size column.

Notice the HTML document and the static assets often carry different cache policies. HTML changes when you publish a post. A versioned CSS file at /app.a1b2.css can sit in a cache for a year because the URL changes when the content changes.

My advice: treat caching as a contract with every intermediary between your server and the user. If you mark a personalized dashboard as public, a CDN might serve one user’s data to another. When in doubt, use private or no-store on anything tied to a logged-in session.