I was wondering though, why would you need a cache-invalidation mechanism. We are developing with angular, but I believe, you can setup things in the same way with React.
We have also been struggling with browser caching, because SEO loves resources cached for as long as possible. So here is our current setup:
js and css files all have a hash part in their filename, so we cache them forever (366 days to be precise), but if they change, the filename changes, so no trouble there.
index.html - never cache it. Here we have references to js and css files.
fonts, images - we cache them forever (366 days again), but we version them all. Therefore, when we update them, we just bump up the version and cache invalidation solved.
This way, SEO performance score is happy that we cache everything forever, but also, we never have to deal with invalid data.
I am not trying to sell my approach here, I am just honestly curious what is your use case for such cache invalidation mechanism? Thanks.
@eddyp23
I am using React but as you mentioned the two are probably largely the same in terms of setup. I am wondering how you would set up the caching for js and css files, do those have to be individually referenced in index.html?
We definitely need to leverage browser and server cache (PWA service worker implementation for cache control is a lot better).
But there are still a few gotchas we haven't solved yet. These "recommended" ways work most of the time but in some rare cases, they won't as I highlighted at the beginning of the post.
So this technique is more of taking control of cache "within your app code" and use this as a fallback approach when all else fails.
We have a peculiar case where I work — safari web app pinned to the home screen and users won't quit it for a few months (restaurant iPads). We simulated native app behavior with PWAs but cache busting instantly after a new deploy was tricky. This technique eventually helped us.
The service worker that comes with react does cause scenarios where the cache is not busted that feel a bit weird. For that reason it was removed from create-react-app a while ago, as discussed here github.com/facebook/create-react-a...
Hi Dinesh, good article.
I was wondering though, why would you need a cache-invalidation mechanism. We are developing with angular, but I believe, you can setup things in the same way with React.
We have also been struggling with browser caching, because SEO loves resources cached for as long as possible. So here is our current setup:
jsandcssfiles all have a hash part in their filename, so we cache them forever (366 days to be precise), but if they change, the filename changes, so no trouble there.index.html- never cache it. Here we have references tojsandcssfiles.This way, SEO performance score is happy that we cache everything forever, but also, we never have to deal with invalid data.
I am not trying to sell my approach here, I am just honestly curious what is your use case for such cache invalidation mechanism? Thanks.
@eddyp23 I am using React but as you mentioned the two are probably largely the same in terms of setup. I am wondering how you would set up the caching for js and css files, do those have to be individually referenced in index.html?
Hey Eddy — Good question.
We definitely need to leverage browser and server cache (PWA service worker implementation for cache control is a lot better).
But there are still a few gotchas we haven't solved yet. These "recommended" ways work most of the time but in some rare cases, they won't as I highlighted at the beginning of the post.
So this technique is more of taking control of cache "within your app code" and use this as a fallback approach when all else fails.
We have a peculiar case where I work — safari web app pinned to the home screen and users won't quit it for a few months (restaurant iPads). We simulated native app behavior with PWAs but cache busting instantly after a new deploy was tricky. This technique eventually helped us.
The service worker that comes with react does cause scenarios where the cache is not busted that feel a bit weird. For that reason it was removed from create-react-app a while ago, as discussed here github.com/facebook/create-react-a...
The mechanism @eddyp23 mentions works perfectly and it's supported by default by create-react-app create-react-app.dev/docs/producti...