custom domain: https://ziba.com
hey guys, we’re facing some cache issue in our site, every time that we update something in the ui, the site changes is not being reflected to users who often access our site (unless they force a hard refresh). So for a test, in the netlify.toml we add in the headers this option last week:
[[headers]]
for = “*”
[headers.values]
Cache-Control = “public, max-age=86400”
but before that, checking the files in the network tab the cache-control for .js files was something like ‘max-age=31536000’, it doesn’t seem correct, does it? (the developer who initially built the site is not in our company anymore for us to confirm)
But after this last change it seems to have fixed the issue, but ‘old’ users are not getting this yet, basically a user was able to access a content in a page that was removed 20 days ago… probably we have something wrong in our settings, would you mind giving some direction?
Is anything that we could change to get the last version to all our current users?
the site was built in next.js 10.
Here is a screenshot from firefox that I took right now, as you can see, the index.js has a version from last year (if I’m not wrong).
and here is after a hard refresh:
any information that could help, please let us know! thank you in advance!
When/how the users browser checks for a new version of the file being viewed is based on the cache-control header that they were sent previously.
If they were sent an instruction of “don’t check for X days”, their browser won’t check for X days, even if you do push up a new version. Deploying new cache-control headers doesn’t automatically propagate them to the cached versions of previous site visitors.
I’m not too sure why you had the header you had, but as you’ve found it’s something that you can control with the configuration.
The default Netlify cache-control header is:
public, max-age=0, must-revalidate
It’s explained as:
“please cache this content, and then do not trust your cache”. This seems a bit counterintuitive, but there’s a good reason. This favors you as a content creator — you can change any of your content in an instant. Let a broken page out in a deploy? Roll back instantly. Want to make sure that your new marketing site all goes out — text, code, and assets — at the same instant so your visitors don’t experience the dreaded new/old mixture that old, file-at-a-time deploy methods left you with? We’re ready!
The full article is here:
1 Like
Thank you for the feedback, and yep, you’re right, I’m not sure why we’re using that setting, but I hope that after the change, it will fix that and then we can start using the netlify one. btw, I’ve added some screenshots, do you mind checking them? Just to make sure that our change is now ‘better’ than the previous one.
But my hope is that we can try some approach to force the users’ browsers to get the last version, any idea?
@helpdesk I’d probably be considered an “expert” at many things, but cache-control is certainly not one of them.
You should look up what you have in documentation to familiarize yourself with it all:
You should take everything I say with a grain of salt, but my understanding is that…
In your first screenshot, the content age is 1749 seconds, so 29.15 minutes.
It’s considered fresh until it reaches an age of 31536000 seconds, so 365 days.
The documentation for immutable says it won’t reach out to re-validate while the content is still fresh, which is based on that max-age.
In the second screenshot, the content age is 2421, so 40.35 minutes.
It’s considered fresh until it reaches an age of 86400 seconds, so 24 hours (1 day).
Neither one is the Netlify default, which I just tend to use because it works for my use-case, which is predominantly low complexity “static sites”.
What you have set is ultimately your decision and should be based on what you’re trying to achieve.
1 Like
@nathanmartin I really appreciated your time by answering me so quickly, and yes, I’ll focus on the documentation and start a few tests.
Still, any other help from the community would be great to solve this 
Hi @helpdesk,
Since this is being discussed in the helpdesk as well, we’ll continue the discussion there.
