Home
Support Forums

Improve Netlify Large Media cache-control header

NLM sets a cache-control: public, max-age=0, must-revalidate header. This makes it impossible to properly cache static assets.

cache-control: public, max-age=0, must-revalidate: Well, I don’t agree with this approach. It is part of the http spec that static assets like images must not change while maintaining the same url. Changing static assets under the same url basically violates that spec. And that makes sense. This provides us with the possibility to cache static assets forever. This is exactly what we should do.

To solve this issue, most tools use GET parameters with hashed or random values to bust caches. And this is what NLM could or should be doing.

I’d suggest having a max-age of at least month or even a year and removing must-revalidate.

Here is a quote from https://web.dev/uses-long-cache-ttl/:

When possible, cache immutable static assets for a long time, such as a year or longer.

Hi, @luksak. You are free to override the default headers that Netlify send using header rules:

Please keep in mind that doing this will break the automatic fine-grain cache invalidation described in the Better Living Through Caching blog post.

The default use of cache-control: public, max-age=0, must-revalidate isn’t going to change, though, as that is required for the fine-grained cache invalidation as described in that blog post to function correctly. This is a core design decision for the hosting at Netlify.

Please note that if you do choose to override these defaults and your site content is cached incorrectly as a result, that our support team won’t be able to fix it as your headers will have removed the mechanism required for us to fix it.

Also, about this:

It is part of the http spec that static assets like images must not change while maintaining the same url.

I don’t believe that statement is true. I have never seen that in an RFC. Sites at Netlify change content at the same URL often. Even with larger enterprise sites do so. It is a very common practice.

If you do believe this is a requirement of the HTTP specification, would you please point out where this is stated?