Browser cache lifetime and Cloudflare edge lifetime control different copies of a resource. Choose them separately so frequently changed content remains updateable while versioned static assets can be reused efficiently.
IN THIS ARTICLE
Information to have ready
Identify how the application publishes changed assets and inspect existing Cache-Control headers. Distinguish a versioned filename from a URL whose contents are overwritten in place.
01 Review browser and edge cache settings
- Review the domain’s browser-cache setting and any matching Cache Rules. Decide whether the origin should define browser lifetime.
- Use a scoped rule when one asset group needs a different policy, leaving private responses protected.
- Set a deliberate browser lifetime and a separate edge lifetime where needed. Avoid a long browser lifetime for a frequently overwritten URL.
- Request the asset and inspect the headers delivered to the browser, then compare Cloudflare’s cache behaviour separately.
- Deploy an updated version using a new filename or controlled URL version and confirm pages reference it. Purge the old edge copy only when appropriate.
Confirm the expected result
The delivered headers should match the intended browser policy, and the edge should retain or revalidate the object according to its own rules. Check real update behaviour as well as performance.
Troubleshoot unexpected results
Purging Cloudflare cannot remotely erase an already fresh browser cache entry. A browser may keep a previously served lifetime even after you shorten the server’s setting, so plan versioned assets before committing to long-lived caching.
Can the edge cache briefly while browsers recheck often?
Yes. Separate origin or Cloudflare controls can define different lifetimes. Verify the resulting headers and keep authentication-sensitive content out of shared caching.
.png)
 (1).jpg)
 (1) (1).png)
 (1).png)
.jpg)
.jpg)
 (1).jpg)
.jpg)
