I am currently working on a progressive web app using the create-react-app
default service worker.
I am having issues with busting the cache when releasing a new version of one of our javascript chunks.
When building, the output javascript files use a contenthash
to make sure that when content changes in the JS file, so does the file name. This successfully busts the cache when running WITHOUT a service worker.
However, when using the create-react-app
service worker, all static assets including my index.html
file is cached. This means that the old index.html
is being served to users, which includes a <script>
tag to my old, cached javascript file(s) instead of the new one with the updated contenthash
.
I have ejected and modified the webpack.config.js WorkboxWebpackPlugin
to exclude my index.html file:
new WorkboxWebpackPlugin.GenerateSW({
clientsClaim: true,
exclude: [/\.map$/, /asset-manifest\.json$/, /index.html/],
importWorkboxFrom: "cdn",
navigateFallbackBlacklist: [
// Exclude URLs starting with /_, as they're likely an API call
new RegExp("^/_"),
// Exclude URLs containing a dot, as they're likely a resource in
// public/ and not a SPA route
new RegExp("/[^/]+\\.[^/]+$")
]
}),
And this seems to appropriately stop the caching of my index file, allowing it to include the updated main.[contenthash].js
in its script tag. However, now I am aware that my PWA will not work offline as the index.html file is not served by the service worker and will not be served from an offline connection.
What is the best way to handle this? Full offline access isn't essential but would be nice to have, and am wondering how other developers are handling the 'busting' of the service worker cache for their index file without fully removing index.html from being cached by the service worker? Is there a more functional way to handle this change in the index.html regarding tags with content hashes?
Thank you
Using a Service worker you can easily set an app up to use cached assets first, thus providing a default experience even when offline, before then getting more data from the network (commonly known as Offline First).
Service worker caching strategies and use cases #It's preferable to serve the fresh content. However if the network fails or is unstable, it's acceptable to serve slightly old content. It's okay to serve cached content right away, but updated cached content should be used in the future.
Caching only matters after the first page is loaded. Service workers honor a life cycle, where they are not active or in control when the first page of a site is loaded in the visitor's first session. You can programmatically make them active after they are registered and become active.
I worked on an app shell architecture where the service worker caches the app shell and returns it for subsequent requests. For Cache busting, I versioned the app shell also, like appshell-[hash].html, so next time when hash changes, the service worker will cache and serve the new app shell discarding the old one.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With