-
Notifications
You must be signed in to change notification settings - Fork 312
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ServiceWorker fetch fast-path #1670
Comments
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 |
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. |
I read the explainer and have tested locally with the Chrome flag active for the experiment I was able to see that with the experiment active,
The problem I see with the
Some thoughts/questions:
Thanks for taking my feedback! |
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.
The text was updated successfully, but these errors were encountered: