Check CDN and browser cache after a release

A purge at the CDN does not clear files already stored in a visitor’s browser. Check the response path before purging broadly or increasing cache TTL.

Compare HTML and versioned assets

• Request the exact page and asset from a clean browser session. Record status, Age, Cache-Control, ETag/Last-Modified, and the CDN cache-status header if present.
• Check that HTML revalidates on navigation and that content-hashed JS/CSS uses long-lived caching. Never apply an immutable, year-long policy to a mutable URL.

Purge only the stale layer

• If the CDN returns old bytes, purge the exact URL or version and recheck from two networks. If only one browser is stale, test a fresh profile before changing edge rules.
• After the change, verify logged-in and public pages separately. Personalized responses should not enter shared caches; capture headers and keep a rollback of the previous rule.

Example and expected result

• Run curl -sS -D page.headers -o page.html PAGE_URL for the page; use distinct names such as asset.headers and asset.bin for the hashed asset. Inspect the saved page.html or compare a build identifier with origin. Repeat both GET requests after deployment and compare Age and the CDN status header; check Cache-Control and ETag too. HTML may not be cached by default, so first inspect the site’s actual rules.
• If only one browser profile is stale, check its service worker and local cache. If the CDN returns an old HIT, purge the exact affected path and repeat in a fresh profile. If origin is old too, fix deployment/origin first. Do not purge unrelated paths.

Primary sources

• Cloudflare · Cache-Control and origin caching
• Cloudflare · Default cache behavior