Netlify calls this Instant Cache Invalidation, part of the “rocketjuice” of Netlify.
On all the sites I work on that aren’t on Netlify, I do have to think about it (ugh). If you look at this very websites source, you’ll see a link to a stylesheet something like this:
<link href="https://css-tricks.com/wp-content/themes/CSS-Tricks-17/style.css?cache_bust=1594590986788" rel="stylesheet">
?cache_bust= stuff at the end of the stylesheet URL? Those are just gibberish characters I put into that URL manually (based on a
Date() call) so that when I push a change to the file, it breaks both the CDN and people’s own browser cache and they get the new file. If I didn’t do that, the changes I push won’t be seen until all the cache expires or is manually removed by users, which is… bad. I might be fixing a bug! Or releasing a new feature! It’s extra bad because that CSS might go along with some HTML which doesn’t cache as aggressively and could lead to a mismatch of HTML and expected CSS.
I work on some sites where I change that cache-busting string by hand because I’m too lazy to automate it. Usually, I do automate it though. I recently shared my Gulpfile which I hand-wrote, and part of which deals with this cache-busting. It is work to write, work to maintain, and work to use during development. You can even read the comments on that post and see other people’s strategies for doing the same thing that are different than how I do it. Errrrrrybody be cache-busting.
Not on Netlify.
Again, you change an asset, push it up, Netlify knows it’s changed and does all the cache busting for you. So your stylesheet can be linked up like:
<link href="dont-even-worry-about-it.css" rel="stylesheet" />
But somehow the article ends unexpectedly. You do not explain, HOW the browser cache is busted with the URL in you last code example…
How does it work?
Netlify also cleans up your public/dist folder before a new build or compile (e.g. with an SSG), normally your build/compile process only writes files, locally you have to clean it up yourself.
A simple function is all that is needed to get around this problem.
And use is also simple.
You can use the same for critical styles.
More here, but I’m just warning the Polish version :)
Sure, but that’s not simple to me. ♀️ I mean there are hard-coded file paths in that function. It’s not incredibly difficult stuff, but it’s technical debt. And it’s another thing that is reading a file off disk, which isn’t performance neutral.
That is why you (CSS Tricks) needs to join the Netlify party!
This just sounds like regular etag based caching. You just have to configure your webserver to serve the proper caching headers, and you can do this without netlify (or any other third party).
I… would struggle with it for a week before giving up ;)
Cloudflare also handles etag caching for you!
Sends the old file while checking for a new version to make sure it hasn’t changed.
If it has, it sends the updated copy to the next person who requests the file, if I remember right.
The big catch here is that every resource needs to be revalidated with the server each time you visit this page. When you fingerprint and cache for one year, you get less rountrips.
This is indeed much easier for development and deployment, but it is a step backwards for performance, as the same resource (CSS, JS, images, etc.) will be downloaded multiple times when browsing the site…
Do you have more detail there? I’d be quite surprised if this meant “Netlify does zero caching”. I think perhaps it’s etag based so a server-ping has to happen to see if there is a new copy of the file, is that what you mean?
That’s it. I was wondering if we could tweak this Netlify cache invalidation to improve performances. For example, I’m used to rename an image when I need to replace one. It’s not needed with Netlify but I would prefer to disable image cache invalidation to improve image loading perf.
It’s true and it works great. Talking about caching on the CDN. Totally not an issue with Netlify.
However how about the browser caching. I find I have to instruct users to hard-refresh the site to pick up changes to the static application script.
I think I will have to do exactly what’s described above to bust the end-user cache on software update, right?