Intent to Prototype: ServiceWorkerAutoPreload

[Shunya Shishido]

Contact emails

sisid...@chromium.org

Explainer

https://github.com/explainers-by-googlers/service-worker-auto-preload

Specification

None

Summary

ServiceWorkerAutoPreload is a 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

Blink>ServiceWorker

Motivation

The ServiceWorker’s fetch handling capability allows developers to intercept and control the resource fetch requests via “fetch” event handler. This enables web apps to be reliable even while offline and delivers faster loading experiences by using its own CacheStorage. However, the cost of starting up a ServiceWorker can be non-negligible. ServiceWorker fetch handlers are invoked during the critical path for navigation and subresource loading. Developers are sometimes using fetch handlers to speed up page loading but the fetch handlers may slow down page loading if the ServiceWorker is not running, or the resource was not cached. In the worst case, it can take up to hundreds of milliseconds to bootstrap the ServiceWorker itself and process fetch event handlers. Fetch handlers are used for various reasons but there are many cases where developers use them with the intention of serving resources faster than the network. To fulfill their intention, this document proposes the introduction of “ServiceWorkerAutoPreload”, a new loading strategy for ServiceWorker.

Initial public proposal

https://github.com/WICG/proposals/issues/155

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

Debuggability

We have a plan to show the info on DevTools when preload requests by this feature are triggered. It's tracked in crbug.com/344912796

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 chrome://flags

Finch feature name

ServiceWorkerAutoPreload

Requires code in //chrome?

False

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5194817700364288

This intent message was generated by Chrome Platform Status.