Wrong Cache-Control makes CDN purge seem ineffective in CI

The edge purge worked but the client still shows old content: a long or immutable Cache-Control on the same URL caches the response in the browser, so purging the CDN does not force a refresh for already-cached clients. The fix is content hashing, not more purging.

What this error means

After a CDN purge, a fresh curl (or incognito window) shows the new asset, but returning users still see the old one. The affected files are served at a stable URL with a long max-age or immutable directive.

HTTP caching

# response cached hard in the browser at a stable URL
cache-control: public, max-age=31536000, immutable
# CDN purge cleared the edge, but the browser keeps its own copy of /app.js

Common causes

Immutable long-lived cache on a stable URL

A file served at the same path with max-age=31536000, immutable is cached by the browser for a year, so an edge purge does not affect clients that already hold it.

HTML cached as long as its assets

When the entry HTML also has a long TTL, browsers keep pointing at old asset URLs, so purging assets alone changes nothing for those users.

How to fix it

Fingerprint asset URLs and short-cache HTML

Emit hashed filenames (app.ab12cd.js) so each build produces new URLs.
Keep long immutable caching on the hashed assets.
Serve HTML with a short max-age (or no-cache) so it always references the newest assets.

HTTP response headers

# hashed assets: safe to cache forever
cache-control: public, max-age=31536000, immutable   # /app.ab12cd.js
# entry HTML: revalidate so it points at new hashes
cache-control: public, max-age=0, must-revalidate      # /index.html

Do not rely on purge for versioned assets

Purging is for shared, non-fingerprinted URLs; for fingerprinted assets, a new build simply produces new URLs and no purge is needed.

How to prevent it

Fingerprint immutable assets so new builds get new URLs.
Short-cache or revalidate HTML entry points.
Reserve purges for stable URLs, not content-hashed files.