Match cache lifetime to URL stability
For fingerprinted assets whose names change with content, a long max-age with immutable behavior can reduce repeat downloads because each release gets a new URL. Confirm your build actually produces unique names before relying on this approach.
For HTML documents, configuration, or assets with stable filenames, use shorter freshness or revalidation so users do not remain on stale content after a release. Sensitive or personalized responses should not be cached publicly unless the application is designed for that behavior.
Verify headers at the delivered edge
Inspect response headers for representative file types from the deployed site, including through any CDN or proxy. A correct origin setting may be overridden or combined with edge rules, so check the value users actually receive.
After changing policy, test both a fresh request and a cached repeat, and confirm invalidation behavior for stable URLs. Avoid purging everything by default; targeted versioned URLs make releases easier to reason about and reduce cache disruption.