Expanded on the update() Note:

[jeffposnick]

@jakearchibald @slightlyoff:

Here's my take on elaborating the update() Note, to clarify that, by default, the browser's HTTP cache is consulted for an unexpired copy of the service worker script, and that update() skips the HTTP cache.

I hadn't previously been clear on whether it was the browser HTTP cache that was consulted or some service worker-specific cache—the impression that I got was that service workers scripts were always cached for 24 hours, and the only way to achieve a quicker cache expiration was to call update().

[jakearchibald]

When loading a registered service worker script, the UA normally checks the HTTP cache for an unexpired copy

This is done when loading a client request occurs, rather than when the service worker script is loaded. Eg, two controlled document loads would cause two updates, even if the SW didn't shut down in between, therefore only loaded once.

update()'s behavior is conceptually the same as what the UA does a maximum once every 24 hours on its own, to prevent service worker scripts from being cached for longer than a day.

Can't decide if "maximum" is misleading. I mean, the UA can check for updates more than once every 24hrs.

[jungkees]

@jeffposnick thanks for having suggested a better wording. Recently after the latest f2f, it has been sorted out that update() obeys the same browser cache rule as other update paths: #514 (comment). And the note has been removed from the text as such.

For

I hadn't previously been clear on whether it was the browser HTTP cache that was consulted or some service worker-specific cache

The fetched service worker script resource is stored apart from the browser cache and has no expiration in and of itself until it's replaced by a new version through one of the update paths.