What Is a CDN Cache? Serving Assets From the Edge

A CDN cache stores copies of your static assets at edge servers around the world, so users download from a nearby location instead of your origin.

Serving every asset from a single origin server is slow for distant users and expensive under load. A CDN caches your build output at edge locations close to users. Getting the most from it depends on how your build names and labels files, which makes caching behavior a direct consequence of the CI build.

How edge caching works

When a user requests an asset, the nearest edge serves it from cache if present, or fetches it from the origin once and caches it for the next user. After the first request, most users get a fast, nearby response.

Cache headers control behavior

Response headers like Cache-Control tell the CDN and browser how long to cache an asset. Hashed assets can be cached effectively forever, while files that change in place must be cached briefly or revalidated.

Immutable assets vs HTML

Content-hashed JS and CSS can be cached long-term and immutably.
The HTML entry must update on each deploy, so it caches briefly.
The HTML references the new hashed assets after a deploy.

Invalidation on deploy

Because hashed filenames change when content changes, a deploy adds new files rather than overwriting old ones, so the cache naturally serves the right version. Files that keep their name, like HTML, may need explicit invalidation.

CDN caching in CI/CD

The pipeline uploads the build output to the CDN and sets cache headers per file type: long and immutable for hashed assets, short for HTML. Doing this correctly in the deploy step is what lets returning users skip downloads while still getting the latest deploy.

Key takeaways

A CDN cache serves assets from edge locations close to users.
Hashed assets cache long-term; HTML caches briefly and points to new hashes.
The CI deploy sets cache headers correctly so users get fast, correct content.