Netlify returns 200 for cached assets

If I open the network tab in my browser when accessing my website, all of the requests look have this header:

Cache-Status: "Netlify Edge"; hit

However, Netlify still returns 200 and the entire asset every time, which means that all of the assets have to be re-downloaded on every page load. I assumed that when the etag stays the same, Netlify should return a 304 and the browser will just use a cached version. Why is this not the case?

Website name is flexagoon.netlify.app but it uses CORS so it’ll only load properly from https://fxgn.dev

Edit: this only happens on Chrome and not Firefox. For some reason, Chrome doesn’t include the If-None-Match header in the request.

That means the request was served from Netlify’s cache. Doesn’t talk anything about the browsers.

As for your site, you’ve also added Cloudflare in front of Netlify and we do not provide support for that configuration.

As for your site, you’ve also added Cloudflare in front of Netlify and we do not provide support for that configuration.

I didn’t add Cloudflare in front of Netlify, I moved my website from Netlify to Cloudflare Pages because it has proper IPv6 suport. When I posted this question, there was no Cloudflare on my website.


In case anyone has the same issue and stumbles upon this post in the future, though: the issue happened due to me having a sandbox; directive in my Content-Security-Policy. I don’t know why it affects caching, but changing it to sandbox allow-same-origin; fixed all of the caching issues.

A status of 304 is not returned on any asset on your site now only a 200 status which goes against the original issue

Yes, because Cloudflare and Netlify use different caching mechanisms, Netlify sets a zero age for caches so they have to be validated via an etag, which means that cached assets will have a 304 code. Cloudflare by default has a non-zero cache age, so cached assets can have a 200 if they aren’t expired yet.

The move to CF had nothing to do with caching though, as I mentioned in my previous comment, the issue turned out to be with the CSP header