Why do we need to do cache busting ?
Static file gets cached and can be stored for a long period of time before it ends up expiring. So ...
For further actions, you may consider blocking this person and/or reporting abuse
What about running a script when you publish that takes all referred files (js, CSS, etc.) And renames them to be
filename.hashOfContents.extension? Make a single change and the cache is automatically invalidated.That will work to invalidate cache in your CDN, but what about the users who are using the app and have cached the files in browser.. You can read more about it in the first series of this blog :)
They won't get an update until they manually refresh or close the browser. (which most of users don't do, as they prefer to suspend the system and continue from where they left in the browser)
My bad! I left out a final piece: don't cache your HTML for longer than maybe a day. Either it is an SPA and the bulk of the data is in JavaScript/APIs or it's a SSR page and you probably want them to see the latest data. I'd personally use a ServiceWorker to show the old cached page if the new page takes more than 1-2s to load.
The method I mentioned above has the benefit of serving the correct JS/CSS for each version of the page. Say I end up using a cached page: my JS and CSS is for that version of the page not the latest version of it. Obviously you need to keep the last n versions for it to work.
Agreed, there's always more than one ways to do it.
Service workers are great, but they are not supported widely in all browser..
But it's great do control your cache.. would love to see your implementation if you can share, so that we can learn.
interesting approach. The disadvantage is of course the loading of meta.json. Here you consume a request.
Yeah agreed, that's a drawback..
In my live app I have optimized to check meta file only on certain routes to avoid hitting meta file on every route change..
Moreover, in my understanding hitting in on the same domain file, which would hardly few bytes is no harm. Considering if you have at least one deployment to production in a week..
The bytes are not necessarily the bottleneck, but the connection. In the worst case you have a complete roundtrip. Of course it depends on the protocol.
RFC contains a few details:
w3.org/Protocols/rfc2616/rfc2616-s...
But that is already complaining on a high level.
For many, your solution should be a viable way.
Hey thanks for sharing the link..
Yeah the complain is on the spot.
A GitHub repo with all the code used in the series will be great
That's a good idea, will post the repo for it
Thanks
I thought webpack has functionality to do this for you?
Umm, I believe what you referring to is unique file names that webpack generates ?
Would love to learn how webpack breaks browser cache too ?
From my high level understanding, you use webpack to generate unique files names for all css and js dependencies, but rely on http cache headers to force browser to reload index.html periodically. (I could be wrong in my understanding). It's not as instant as your solution, since it relies on browser rather than interactively triggering reload directly inside of the react app. I would use your solution for thousands of user. I would use something simpler for hundreds of users.
It consist of two things:
This solution causes the app to be stuck in an infinite loop as it keeps on refreshing because
packageVersion < metaVersionwould be true always.No it won't be true always if you have set header's of meta.json file to have not cache using CloudFront policies.
Or manually settings headers for this to for
no-store.In this case it will always be a new version from next deployment.
Let me know if I was able to help ?