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

I've mentioned some of this in the 3rd paragraph but let me elaborate. The key point is that there's valid use cases to disable the fetch listener significantly after the `activate` event. The user can log out, the SW cache may expire, cache can be explicitly busted by some signal. Then the `fetch` event could be re-registered after something occurs like user login or cache update/re-validation.

In general `fetch` is bad for performance so we only want it enabled if we're able to benefit from it to overcome the ~5% startup overhead we see which is when we have valid cache that isn't disabled for the above reasons. Recent improvements to the implementation, particularly background fetch, will reduce the overhead but I believe it will remain significant.

I think this situation is similar to `wheel` and non-passive listener. Improvements in the implementation allowed better scrolling but there was always going to be significant overhead to having listener that blocked the scroll or fetch in this case. For `wheel` events, authors can opt to having a non-passive listener when they need to act on the event or they can un-register the listener when they don't which sites will do to minimize the time scroll blocking listeners are active and slowing down scroll latency. (There's no use case for a passive `fetch` listener at this point.)

Having finer control over the `fetch` handler allows us to easily turn off `fetch` without any coupling to the state of `push` functionality of the service worker.

-- 
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#issuecomment-331536500