[w3c/ServiceWorker] Consider mechanisms to bypass the service worker for things that we know won't be in it's cache (#1026)

### The Problem

There will always be some number of resources that we cannot cache in the Service Worker. Perhaps this is segments of a 360 VR video or something like a profile picture that just changed. In many case it's possible that the client will know in advance that the Service Worker does not have this resource cached yet the request for it still need to go through the Service Worker.

Right now the process of sending a request from the main thread to a Service Worker can take a few milliseconds in many implementations. Then we have to wait on the event loop in the Service Worker (which we always have to do even in the best case scenario). Facebook tends to send large bursts of resource requests as the page loads. If we send 40 or so requests from the window at once, while the first few may be quick, the other events get tacked onto the end of the Service Worker event loop and end up getting delayed quite a bit before they can hit the network. Even though the Service Worker won't call respondWith for these events they still get delayed by the busy Service Worker event queue.

### Proposed Solution

The window will generally know it has a resources that there's no way the Service Worker has in cache. It'd be nice if there was a way for the service worker to be totally bypassed when this resource is requested. Perhaps this is an API on the service worker registration that lets you mark URLs as bypassable, perhaps we add this as a fetch option and let you add fetch options to html tags, perhaps we come up with some url scheme that let's you bypass the sw. I'm not sure what the right solution is, but I'd like to start thinking about what one could be :)


-- 
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/1026