Imagine you make service worker that implements an 'offline first' strategy (the typical use case for service workers), and you deploy it to production, but it has a bug. The bug means that it never actually checks with the origin server for updates, even to itself. So after the service worker is registered for a given client on their first visit, that client would never see any update to that website again (unless the user manually unregisters the service worker using chrome://serviceworker-internals/
or something). In other words, the site is broken forever for those users.
Is the above scenario possible? If so, is there a strategy for making sure it never happens?
The first power a service worker brings to a web site is the ability to enable offline capabilities with granular control. This is done with a rich caching API and intercepting all network requests before they leave. Caching not only enables offline experiences, websites can load instantly when retrieved from cache.
Not to be confused with the Service Worker Life Cycle, the time a browser keeps a site's service worker active once it has been triggered varies by browser and is what we are discussing here. When a user opens a page associated with a registered service worker and the service worker is not active the browser instantiates the service worker.
If the service worker is not already running, there is usually an overhead in starting it up. Many browsers optimize on that by not starting up the service worker on network requests unless a fetch handler is defined. Registering a fetch handler that doesn't do anything leads to consuming resources on the user's device unnecessarily.
When a service worker is installed it does not immediately become active. The natural sequence is for a new service worker to wait until all service worker 'clients' are closed. The reason service workers are designed not to immediately take over is to keep them from breaking the user experience.
There will be no perma break, you can always update your service worker and fix the caching issue you've made.
But there will be chances that something will never be updated if you forgot to update your cache and use it correctly. (regarding the first point, you can always fix this, no perma break)
As far as I know there are some bad scenarios when you are rely too much on using caches, BUT it is depends on the strategy, it is not likely happen on "offline first" strategy but the others.
As if you have an advance knowledge about Service Worker, you will know we can do some sort of network balancing for certain request of browser. For sort we can do something like:
Offline first
Online first
Fastest
Online only
Offline only
etc.. (the names are only for illustrations)
And if you are going with something like Offline only for certain files/places, you may ended up with that places/files will never be updated.
So the answer is: there always chances that something went wrong, but for the thing you are worrying it is likely not always happen. If you want to prevent it make sure to always update the cache content for Offline first when it is available
To add up the answer of @anshulix I am not sure if that behavior was from old service worker. But for my recent experiment, regardless what you are doing, if service worker ONCE INSTALLED, it will always try to update itself ONCE every time you load the site.
With this you can always fix your mistakes right away and end-user will got the fix after first site loaded or second site loaded.
haha, no it doesn't happen this way, service-worker file has a periodic update in 24 hours, even if the first service-worker was buggy, it would always check on server if there are any changes and updates.
mdn
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