[w3c/ServiceWorker] Proposal: Allow addEventListener/removeEventListener for 'fetch' to called at anytime (#1195)

As both Google and Facebook has found, there’s a high measurable overhead to routing fetches through the service worker.
 
w3c/ServiceWorker#718 implemented a great partial solution and I ran an A/B control experiment at Facebook and confirmed it showed a large startup benefit for our push-only service worker. This change requires the Service Worker to decide on first evaluation to register a fetch handler or not. This is saved on the SW registration and this value is retained. After this it’s impossible to change your mind so the work around is to force installing a new service worker to get this new first run.
 
However, this leaves out a lot of practical use case where a service worker may change its mind. For instance, a service worker may choose to disable ‘fetch’ caching if a user is logged out if the caches contain sensitive information. Or the caches may simply expire and be incompatible with the current server version. I don’t think it’s reasonable to lock-in a service worker to listen to fetch event for its full lifetime and pay the performance overhead.
 
Right now, the work around is to force install a new service worker, bypassing HTTP caches, use skipWaiting to force the new service worker to activate. This is very complicated to get right compared to simply maintaining addEventListener and removeEventListener for your fetch event.

This current approach passes on a lot of complexity to the service worker developer and establishes a bad precedent to addEventListener. See whatwg/dom#371 for discussion.
 
As I see it, the service worker shutting down is, for the most part, done as an optimization. If the service worker is shutdown while there’s no ‘fetch’ event then there’s no point in waking up the service worker since it wouldn’t be able to observe the fetch had it not been shutdown. If there’s a current ‘fetch’ listener or there was one at the time of the shutdown then the fetch should be handled by the service worker. I see no point in disallowing that to change after first run.
 
The service worker should continue to block on the ‘activate’ event completion before deciding if the navigate event should be handled or not. That gives an appropriate chance for a service worker to activate and decide if it wishes to handle all requests without missing the first navigate. It also lets the service worker a chance to change its mind and removeEventListener(‘fetch’, handler) because it decides that caching is no longer viable and is unlikely to overcome the performance overhead of having the fetch handler.
 
>From Facebook’s experience the ‘fetch’ handler adds significant overhead. When caches and the server are in the right state then the ‘fetch’ handler is able to overcome the overhead of listening to all web request and provide an overall win. However, in some cases we may deactivate the cache in which case it would be preferable to remove the ‘fetch’ listener and only listen to push events. Updating addEventListener and removeEventListener would allow this naturally and it would resolve whatwg/dom#371 by not requiring any change there.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1195