CDN Caching vs Browser Caching: How They Work Together

The browser HTTP cache sits on the user device. A fresh cached response can be reused with no network request. A CDN cache sits between users and the origin. A hit still crosses the network, but it usually travels to a nearby edge and avoids application and database work.

The layers can cooperate. A CDN may serve the first request and the browser may reuse the response for later navigation. Shared-cache directives can allow the edge to store content longer than the browser when you want frequent client revalidation without repeated origin work.

max-age controls browser freshness; s-maxage can set a different freshness lifetime for shared caches. public permits shared caching, while private restricts storage to private caches. no-store asks caches not to store the response. Validators such as ETag or Last-Modified support conditional requests after freshness expires.

Do not choose headers by file extension alone. HTML can be public and cacheable; an image download can be private. Base the policy on whether the response varies by user, authorization, cookie, locale, device, or other request properties.

Give JavaScript, CSS, font, and image assets content-based names such as app.a83f2.js. When bytes change, the URL changes. That allows a long max-age without serving stale content after a deployment. The HTML references the new asset and old clients can continue using the old immutable URL safely.

Avoid invalidating an entire asset directory on every release. URL versioning creates deterministic cache behavior and preserves the hit ratio for files that did not change.

A public article or product list can often tolerate a short shared TTL plus stale-while-revalidate. Even seconds of edge freshness can absorb a traffic spike. Use explicit purge events or surrogate tags when an immediate business update must invalidate related pages.

Never cache a personalized or authenticated response in a shared cache unless the key and policy are designed and tested for that exact variation. A high hit ratio is not worth leaking one user’s content to another.

Cookies, query parameters, and request headers can fragment the CDN cache. Forward only the values that actually change the response and normalize parameters where safe. Keep tracking parameters out of the cache key when they do not affect content.

Inspect Age, Cache-Control, Vary, ETag, CDN cache-status headers, and repeated-request timing. Measure hit ratio by content type and edge location. Test stale behavior, purges, deploys, authorization, and error responses before declaring the configuration complete.

CloudFront and the browser should receive intentionally different freshness instructions. Versioned assets can stay immutable in both layers for a long time. HTML often needs a short browser lifetime so users discover new releases, while CloudFront can use controlled revalidation or a modest edge lifetime to protect the origin. Personalized and authenticated responses need stricter cache keys or no shared caching at all.

Document cache keys alongside TTLs. Forwarding every cookie, header, and query parameter can fragment the CloudFront cache until hit rate collapses; ignoring a meaningful variant can serve the wrong response. The secure static web architecture is a useful starting point for separating cacheable assets from dynamic API calls.

Release behavior is part of the design. Prefer content-hashed assets and deploy HTML after the referenced files exist. Reserve invalidations for exceptional corrections or paths that cannot be versioned, then verify `Age`, `Cache-Control`, validators, and CloudFront cache status on the public URL. The CloudFront optimization guide goes deeper into origin and cache behavior choices.