consider fetching service worker scripts with no-cache by default

[wanderview]

Lately I've found myself recommending to people that they use Cache-control: no-cache or max-age: 0 on their service worker script resources. It seems best practice in order for service worker updates to be detected as devs expect.

Should Update algorithm just fetch the service worker script with Request.cache='no-cache' by default? One could argue that an "update check" is semantically similar to pressing the refresh button.

Edit: Removed the erroneous statement about the firefox http cache.

[delapuente]

This could be tweak for production environments by adding an option to the registration:

navigator.serviceWorker.register('worker.js', { cache: <policy> });

[jakearchibald]

I'm pretty open to this, it does seem like a gotcha. I use & recommend max-age=0 on all service workers. An option to re-enable the current behaviour would be nice too.

The only reason that it feels "wrong" is because avoiding the cache is the exception, but it does feel like the pragmatic option in this case.

Interested to know the opinion of those doing a lot of SW development. +@naskooskov @n8schloss @bmaurer.

[muralisr]

This would be really useful for companies providing services via service workers. We are deploying SW onto clients who can host scripts, but don't have a straight-forward way to set response headers.

[n8schloss]

So, for us the current behavior is actually kind of useful. When we push out new code for the site we'll slowly ramp things up and some Facebook servers will be on the newest version while some will be on the old version. In the middle of the code push for any individual request it's just as likely that someone will hit new code or that they'll hit old code. For service workers this means that during code push we often see service workers constantly in the upgrade state. We have some mechanisms to ensure that we don't install an old version of the service worker, however we did still enter the install state more than is ideal. To solve this we actually cache the service worker script for an hour, this allows a level of stability that would otherwise be hard to achieve.

[n8schloss]

(that being said, I do agree that defaulting to no cache with an option to re-enable the current behavior is probably a better developer experience)

[inian]

Coming from same perspective as @muralisr (we provide service workers to our clients and we are not in direct control), we find that they usually cache the service worker script similar to other JS files on their server, which tends to have a long cache time if they are doing things correctly. They should ideally add a separate server rule making the service workers script cache for a lesser time which they typically do not end up doing.

I like @delapuente's way of declaring the cache time during the service worker registration process.

[jakearchibald]

Pre F2F notes: do we want to make this change? We shouldn't do it without offering an API to stick with the current behaviour. Should these options be part of the registration call, or in the activate event?

[jakearchibald]

F2F:

• It'd be great to make max-age opt in, but need to speak to big SW users first
• Feels like this should be a setting on the install event

[jakearchibald]

• We should do the above for all imported scripts & modules

[jakearchibald]

• Even in the opt-in cache case, we still do the 24hr limit

[wanderview]

Gecko bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1290944

[jakearchibald]

At the moment third party servers can use max-age to reduce server load, are we kinda going against them here by making this opt-in by a different origin?

[jakearchibald]

Regarding the opt-in: the concurrent fetch feature will sit on the registration object, so maybe this should too.