Classify the response
A browser cache belongs to one client; a shared cache can serve several clients. A personalised response needs deliberate handling. The presence of a cookie does not by itself make a response private. Cache-Control directives communicate storage and reuse rules, but a managed CDN can have additional configuration. Check both layers.
Make a small inventory of response types before setting a global rule. Typical entries include public article HTML, versioned stylesheets, authenticated pages and error responses. Give each type an owner and a clear reason for its policy.
Plan how a correction reaches readers
A long-lived asset can be convenient when its URL changes with its content. HTML often needs a different approach because an editor may correct a factual error without changing the page address. The practical question is how soon an existing reader will see that correction.
Rehearse a release using two versions of one article and one stylesheet. Open the old page, deploy the new files, then revisit it. Record what happens with and without a reload. Test through the actual CDN because a local file preview says nothing about response headers.
Keep a cache incident small
Start a troubleshooting note with the affected URL, the observed content, the expected content and the time of the release. Compare response headers at the origin and at the public endpoint. Avoid purging everything before collecting the evidence that could explain the mismatch.
Write down who can invalidate cached content and how to confirm that invalidation worked. For sensitive pages, verify that one visitor cannot receive another visitor’s response. A fast page that returns the wrong content has failed its most important job.
Before you finish
- Public and personalised responses separated
- Correction propagation tested
- Origin and CDN policies compared
Technical reference
MDN: HTTP caching