Re: [w3c/ServiceWorker] ServiceWorker fetch fast-path (Issue #1670)

I read the explainer and have tested locally with the Chrome flag active for the experiment `Bypass Service Worker Fetch Handler for main resource`.

I was able to see that with the experiment active,
* requests for main documents were handled directly by the browser and bypassed a Service Worker fetch handler — even when the Service Worker was active.
* requests for all other resources besides main documents can be fetched via Service Worker.
* pages can still be pre-rendered using the Speculation Rules API.

The problem I see with the `ServiceWorkerBypassFetchHandler`: 
* If it were to become a default, developers could no longer leverage Service Workers to optimize main documents prior to their loading. We at [Speed Kit](https://www.speedkit.com/), for example, use a SW on main docs and are able to significantly reduce their _Time to First Byte_ (TTFB), which more than compensates for any SW overhead.

Some thoughts/questions: 
* As a developer, how could I tell the browser that I explicitly want the Service Worker to handle all requests — even those for main documents? How could I override the `ServiceWorkerBypassFetchHandler`?
* With the aim of offsetting Service Worker bootstrap latency, shouldn't the `ServiceWorkerBypassFetchHandler` just bypass the fetch handler when a Service Worker is installing or waiting and not when it's active?
* As asked in the explainer, "What if there was a way to tell the browser in advance which resource requests can bypass the fetch handler?" What if devs could suggest to the browser when to bypass the fetch handler by adding an attribute to specific links (similar to the [`fetchpriority`](https://wicg.github.io/priority-hints/#solution) priority hint)?
* What if the browser bypasses the fetch handler just on devices with weaker processors and less memory? 

Thanks for taking my feedback!

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1670#issuecomment-1433118602

You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1670/1433118602@github.com>