I see. We could consider triggering a periodic update check for frequently used service workers.

You're right that there is currently no periodic service worker update check. However service worker updates are triggered in more cases than visiting a controlled page. Running a service worker can triggers an update if it hasn't been updated in a while (24 hours). So, e.g., if you get a push notification, by the time you tap the notification the worker may have already been updated.

The idea is that unused service workers shouldn't incur network/cpu costs, even for the update check. But we could potentially hook into site engagement  and do periodic updates even when the SW isn't being used. I'm not sure the latest story on site engagement.

This should probably be discussed as a spec issue.

And I think the spec might have used to have automatic updates in the background but it was removed from the spec.  For example this issue mentions "controllers must be checked every 24 hours":

https://github.com/w3c/ServiceWorker/issues/43

Jake, do you recall why it was removed?

I think the spec permits it in Soft Update: "The user agent may call this as often as it likes to check for updates."

True, but it feels like an interop issue if sites have to deal with update-on-navigate for some browsers, but get background update for other browsers.

Ah I thought we'd still do update-on-navigate all the time, and in addition to that sometimes do spontaneous Soft Update for frequently used SWs.

Also want to mention that "Add to homescreen" could be another useful signal in addition to high engagement to determine soft update eligibility. Users could use an web app only occasionally but think it is important enough to install to their device and may want an up-to-date version when they do launch it.

Kenji: Adding for PM visibility to help gauge priority.