ServiceWorker fetch fast-path

[sisidovski]

We (Google Chrome team) are working on performance improvements on ServiceWorker, and we'd like to hear feedback for “ServiceWorker fetch fast-path” concept from the community.

The cost of ServiceWorker is not cheap, it can take up to hundreds of milliseconds to bootstrap the ServiceWorker itself and process fetch event handlers. "ServiceWorker fetch fast-path" reduces this cost by introducing the path that the request will immediately happen and go directly to the network, without waiting for the ServiceWorker bootstrap and bypass fetch handlers.

Please see the explainer for more details, and we've sent Intent to Experiment to the blink-dev group, to start the Origin Trial so that interested parties can join the experiment.

Our primary target is the main resource (navigation request). If the upcoming experiment brings good results, we will consider expanding this approach to specific subresources. Also, we don’t yet have a concrete idea for the proper API surface to enable this feature. Perhaps it will be the subset of the Declarative Routing API #1373 proposed by @jakearchibald or similar. Any feedback or API proposals are welcomed: for the main resource case, and for the subresource scenarios.

[bathos]

Being able to declare “don’t bother” carve outs for resources known to never need the service worker was something I’d wished for a few times in past work. It would have been especially useful if match conditions permit fetch destination to be a factor, e.g. it was known that all image resources without /a-specific-path-prefix/* were given no special handling in the service worker.

[jakearchibald]

My worry is that we'd end up with lots of carve-outs that don't really work together. I'm not against shipping the declarative routing API in stages, but I'd like it to be part of a cohesive design.

[screenspan]

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, 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 booting and not when it's active? And doesn't that happen anyways when the Service Worker is not yet active and cannot handle fetches?
• 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 priority hint)?
• What if the browser bypasses the fetch handler just on devices with weaker processors and less memory?

Thanks for taking my feedback!