Reputation: 6193
I'm using sw-precache to generate my service work with Polymer CLI build process, so it's intended to update the hash of updated files to signal a need to update the cache. But my updated content is not being replaced in cache, so it's getting an old version if I refresh with ctrl+r but the new version if I refresh with ctrl+shift+r. A reason for that can be that my service worker is not being updated.
This doc states that
If there is even a byte's difference in the service worker file compared to what it currently has, it considers it new.
, but what if my new service worker didn't change a byte? (as it happens if just one hash has changed). How to configure the sw-precache to update the service work at every new request?
Upvotes: 28
Views: 63443
Reputation: 31658
service‑worker.js
A one-character change in the controlling service-worker.js
will automatically trigger a PWA update. Hence, if you store the version number in a const
in this file and change it, an update of the PWA will be triggered.
How the update eventually is handled, is determined by the service-worker.js
. Different update strategies may be defined in terms of the size and volatility of the PWA assets.
However, there is one important caveat. Make sure that the browser cache expiry directive set by the .htaccess
file on your asset server is set to a really short duration (e.g. hours
) or even to none.
Failing to do so, will result in the browser not seeing any change for days to come in the manifest.json
, nor the service-worker.js
.
More details about service worker behaviour are available from Google Web Fundamentals.
Upvotes: 3
Reputation: 512
One option that I have implemented from a UX standpoint is calling the unregister method on your service worker. (https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerRegistration/unregister)
Once the unregister process is complete you can:
I have ran into weird issues with the service worker before, so this type of solution allows you to somewhat clear the old cache and refresh the state of your application without forcing users to clear their actual browser cache, while at the same time reloading your application.
EX (How to Unregister):
serviceworker.unregister()
.then( unregResult => {
//You can check if successful with Promise result 'unregResult'
window.location.reload();
})
Upvotes: 4
Reputation: 1
const messaging = firebase.messaging();
messaging.setBackgroundMessageHandler(function(payload) {
//Force the Service Worker to Upddate
self.registration.update();
const notification = JSON.parse(payload.data.notification);
return self.registration.showNotification(notification.title, notification);
});
Upvotes: -4
Reputation: 469
'sw-precache' has been superseded by Workbox which generates hashes for the files you want to precache and adds those to the source code of your service worker (I don't know if sw-precache
works the same way, Jeff's answer suggests it does). If any of the files you want to precache change -- and you re-run your build -- the updated hashes in your service worker are updated which pretty much guarantees the service worker will be "at least one byte different".
When you reload (ctrl-r
) or re-visit your app the browser will fetch again the service worker that was registered for it. And, if that service worker has changed, it will be "queued up" to manage the app. But it won't start managing the app until you close all tabs with the app open, and then open a new one.
When you hard refresh (shift-ctrl-r
) it’ll always load without a controller which is not the same as using your new service worker.
For testing during development, I use skip waiting in devtools to make the new service worker replace the old one without waiting for me to close all the tabs.
Upvotes: 14
Reputation: 1020
As the previous answers stated, there is a 1 day (24hr) built-in limit for the browser to look for updates to the service worker, but what you need to be mindful of is you still need to call .update()
on your ServiceWorkerRegistration
object otherwise the original version of the file will be used.
While testing changes in Chrome, I always right-click on the refresh button and select 'Empty Cache and Hard Reset' (options are available when developer tools are open) when working on my service worker script.
Upvotes: 21
Reputation: 56164
If one file's hash changes, that's enough to ensure that the service worker JavaScript file generated by sw-precache
changes. That, in turn, is enough to trigger the service worker update flow.
If you're not seeing an update flow triggered while testing things out, then it may be due to the service worker JavaScript file being served with HTTP caching headers that cause it to be fetched from the browser's cache rather than the from the network.
See https://stackoverflow.com/a/38854905/385997 for a discussion of how HTTP caching headers come into play, and the best practices with regards to that.
Upvotes: 11