Service worker JavaScript update frequency (every 24 hours?)

Question

As per this doc on MDN:

After that it is downloaded every 24 hours or so. It may be downloaded more frequently, but it must be downloaded every 24h to prevent bad scripts from being annoying for too long.

Is the same true for Firefox and Chrome? OR does update to service worker javascript only happens when user navigates to site?

Scop

Answer 1

Note: As of Firefox 57, and Chrome 68, as well as the versions of Safari and Edge that support service workers, the default behavior has changed to account for the updated service worker specification. In those browsers, HTTP cache directives will, by default, be ignored when checking the service worker script for updates. The description below still applies to earlier versions of Chrome and Firefox.

Every time you navigate to a new page that's under a service worker's scope, Chrome will make a standard HTTP request for the JavaScript resource that was passed in to the navigator.serviceWorker.register() call. Let's assume it's named service-worker.js. This request is only made in conjunction with a navigation or when a service worker is woken up via, e.g., a push event. There is not a background process that refetches each service worker script every 24 hours, or anything automated like that.

This HTTP request will obey standard HTTP cache directives, with one exception (which is covered in the next paragraph). For instance, if your server set appropriate HTTP response headers that indicated the cached response should be used for 1 hour, then within the next hour, the browser's request for service-worker.js will be fulfilled by the browser's cache. Note that we're not talking about the Cache Storage API, which isn't relevant in this situation, but rather standard browser HTTP caching.

The one exception to standard HTTP caching rules, and this is where the 24 hours thing comes in, is that browsers will always go to the network if the age of the service-worker.js entry in the HTTP cache is greater than 24 hours. So, functionally, there's no difference in using a max-age of 1 day or 1 week or 1 year—they'll all be treated as if the max-age was 1 day.

Browser vendors want to ensure that developers don't accidentally roll out a "broken" or buggy service-worker.js that gets served with a max-age of 1 year, leaving users with what might be a persistent, broken web experience for a long period of time. (You can't rely on your users knowing to clear out their site data or to shift-reload the site.)

Some developers prefer to explicitly serve their service-worker.js with response headers causing all HTTP caching to be disabled, meaning that a network request for service-worker.js is made for each and every navigation. Another approach might be to use a very, very short max-age—say a minute—to provide some degree of throttling in case there is a very large number of rapid navigations from a single user. If you really want to minimize requests and are confident you won't be updating your service-worker.js anytime soon, you're free to set a max-age of 24 hours, but I'd recommend going with something shorter on the off chance you unexpectedly need to redeploy.

Whirlwind

thanks Jeff for nice explanation. clarified all queries. – Scop

what happens if a service-worker call is intercepted in the fetch and cached. Does that also expire after a day. – Copley

A service worker's fetch event handler is not triggered when the page requests a service worker script to register. – Whirlwind

>they'll all be treated as if the max-age was 1 day. doesn't this pretty much defeat the purpose of service workers? if my app is disconnected from the internet for 24 hours it stops working and there's nothing I can do about it? All just to save users from having to know about clearing their cache, or developers from adding a cache-buster to their urls. Am I missing something? – Errantry

"If my app is disconnected from the internet for 24 hours it stops working" is not correct. Your previously cached content, and previously cached service worker JS files, will continue to be used whenever you're offline. This post contains details that pertain to when you're online, and how frequently updates are checked for then. – Whirlwind

What happens if the service-worker.js file is REMOVED from the server and and installed SW tries to refresh itself? Will it deregister itself altogether, or else how do you get rid of an old SW which you do not want your clients to use at all anymore (rather than update it)? – Bedsore

No, there is no automatic unregistration. See github.com/w3c/ServiceWorker/issues/204. You need to either respond to the service worker update request with a valid, if empty, JS response, or alternatively, execute code in the window context of the web pages that explicitly unregisters the SW. – Whirlwind

I'm going to develop a pwa that uses the SvelteJS framework. When I use the Fetch API to make a request to an API, does it check for a new service worker file? Can I do this update manually with a fetch request? – Barry

Answer 2

Some developers prefer to explicitly serve their service-worker.js with response headers causing all HTTP caching to be disabled, meaning that a network request for service-worker.js is made for each and every navigation.

This no-cache strategy may result useful in a fast-paced «agile» environment.

Here is how

Simply place the following hidden .htaccess file in the server directory containing the service-worker.js:

# DISABLE CACHING
<IfModule mod_headers.c>
    Header set Cache-Control "no-cache, no-store, must-revalidate"
    Header set Pragma "no-cache"
    Header set Expires 0
</IfModule>

<FilesMatch "\.(html|js)$">
    <IfModule mod_expires.c>
        ExpiresActive Off
    </IfModule>
    <IfModule mod_headers.c>
        FileETag None
        Header unset ETag
        Header unset Pragma
        Header unset Cache-Control
        Header unset Last-Modified
        Header set Pragma "no-cache"
        Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate"
        Header set Expires "Thu, 1 Jan 1970 00:00:00 GMT"
    </IfModule>
</FilesMatch>

This will disable caching for all .js and .html files in this server directory and those below; which is more than service-worker.js alone.

Only these two file types were selected because these are the non-static files of my PWA that may affect users who are running the app in a browser window without installing it (yet) as a full-fledged automatically updating PWA.

More details about service worker behaviour are available from Google Web Fundamentals.

Aether