Contact emailssisidov...@chromium.org Explainer https://github.com/explainers-by-googlers/service-worker-auto-preload
SpecificationNone 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 componentBlink>ServiceWorker <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EServiceWorker> 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 proposalhttps://github.com/WICG/proposals/issues/155 TAG reviewhttps://github.com/w3ctag/design-reviews/issues/963 TAG review statusPending 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 <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ?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 nameServiceWorkerAutoPreload 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 <https://chromestatus.com/>. -- 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+unsubscr...@chromium.org. To view this discussion on the web visit 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.
