Intent to Experiment: ServiceWorkerAutoPreload
Shunya Shishido
Contact emails
Explainer
https://github.com/explainers-by-googlers/service-worker-auto-preload
Specification
None yet, we’ll write one after the experiment.
Summary
ServiceWorkerAutoPreload is the mode where the browser issues the network request in parallel with the ServiceWorker bootstrap, and consumes the network request result inside the fetch handler if the fetch handler returns the response with respondwith. If the fetch handler result is fallback, pass the response directly to the browser.
Blink component
TAG review
https://github.com/w3ctag/design-reviews/issues/963
TAG review status
Pending
Risks
Interoperability and Compatibility
For compatibility risks, the main concern is about how this feature works with the navigation preload API. But we don't think this feature introduces major compatibility issues because this feature respects the navigation preload API, and is not exposed when the navigation preload API is already enabled.
The only cost is the server side cost to respond to the network requests, which may not be used if the fetch handler returns a result from the disk cache. This cost can be mitigated by applying the feature only for websites that meet some criteria e.g. fetch handler always fallback to the network
Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1036)
WebKit: No signal (https://github.com/WebKit/standards-positions/issues/359)
Web developers: No signals
Other signals:
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
Goals for experimentation
Our intent is to run a Finch experiment on 1% Stable instead of Origin Trials, because this feature is only exposed with heuristics and it doesn't have an API surface.
We run the experiment to evaluate the potential impact of ServiceWorkerAutoPreload on the loading metrics. And also we’d like to gather inputs and feedback to decide a reasonable criteria, or conditions to enable ServiceWorkerAutoPreload when it’s fully launched.
Conversely, currently we don’t have a plan to ship this feature as it is without any criteria or conditions.
Experiment Risks
The cost of this feature is to increase the server side cost to respond to the network requests. For the experiment, we are going to enable the feature on 1% traffic.
Ongoing technical constraints
None
Debuggability
We have a plan to show some info when the preload requests by this feature are triggered on DevTools. It's tracked in crbug.com/344912796
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
No
Is this feature fully tested by web-platform-tests?
No
Currently we don't have WPT tests. As this feature is only exposed with heuristics and it doesn't have an API surface, it's not testable on the WPT infrastructure.
Flag name on about://flags
#service-worker-auto-preload
Finch feature name
ServiceWorkerAutoPreload
Requires code in //chrome?
False
Estimated milestones
Estimated milestones are for Finch, not for the Origin Trials.
desktop first 131
desktop last 136
Android first 131
Android last 136
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5194817700364288?gate=5100561098866688
Links to previous Intent discussions
Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGMyg-btkw3n_k0Vr9GgW%2B_c%2BT5K%3D_1_BPFstqAVi0y%3DxxT-pg%40mail.gmail.com
This intent message was generated by Chrome Platform Status.
Chris Harrelson
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGMyg-YF1qRNkBUPGxN-GgDGG3yvqCijZ56QEQYgNA4a9YrfMg%40mail.gmail.com.