2025年7月25日(金) 10:44 'Daniel Clark' via blink-dev <blink-dev@chromium.org>:
> This looks like a nice optimization. > > > Specification > > https://github.com/w3c/ServiceWorker/pull/1756 > > What needs to happen for this PR to land? It looks like there are a couple > minor things from 2 weeks ago that need to be addressed. Since the WebKit > reviewer has now approved, could it be landed after that? > I am a reviewer of the PR, and the remaining part is addressing comments there. > Regarding a site's eligibility for the feature -- could you clarify the > criteria you plan to ship with? The explainer section at > https://github.com/WICG/service-worker-auto-preload?tab=readme-ov-file#eligibility-criteria > seems > to have been written before the experiment > <https://github.com/WICG/service-worker-auto-preload/issues/3>, so I'm > curious as to whether your thinking on that is still the same. > Upon the PR, there are no additional criteria needed. Network requests may always be sent if the feature is not explicitly disabled. I hope @Shunya Shishido <sisidov...@google.com> to explain the details. > Also, point (1) there is not so clear :"Higher rates of fetch handler > results are fallback." Is there a specific rate you have in mind, and how > is that determined? > Have you talked to the WebKit folks to see what eligibility criteria they > plan to use for their version of the feature? > > -- Dan > > ------------------------------ > *From:* Shunya Shishido <sisidov...@chromium.org> > *Sent:* Wednesday, July 23, 2025 12:54 AM > *To:* blink-dev <blink-dev@chromium.org> > *Subject:* [EXTERNAL] [blink-dev] Intent to Ship: ServiceWorkerAutoPreload > > You don't often get email from sisidov...@chromium.org. Learn why this is > important <https://aka.ms/LearnAboutSenderIdentification> > Contact emails > sisidov...@chromium.org > > Explainer > https://github.com/WICG/service-worker-auto-preload > > Specification > https://github.com/w3c/ServiceWorker/pull/1756 > > Summary > > ServiceWorkerAutoPreload is a mode where the browser issues the network > request in parallel with the service worker 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, it passes the network response directly to the browser. > ServiceWorkerAutoPreload is defined as an optional browser optimization, > which will change the existing service worker behavior. We expect the > impact on Enterprise is low, but the temporary enterprise policy called > ServiceWorkerAutoPreloadEnabled will be added to control this feature. > > > Blink component > Blink>ServiceWorker > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EServiceWorker%22> > > TAG review > https://github.com/w3ctag/design-reviews/issues/1108 > https://github.com/w3ctag/design-reviews/issues/963 > > TAG review status > Pending > > Risks > > > Interoperability and Compatibility > > For compatibility risks, the main concern was 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 reduced by applying the feature only when > the service worker is not started, or 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) Although we are > still waiting for WebKit's official standard position, we believe they are > supportive. A reply on the proposal mentioned that it 'seems inline with > what WebKit is implementing,' and a WebKit reviewer has already approved > our spec change PR. > https://github.com/WICG/proposals/issues/155#issuecomment-2873318636 > https://github.com/w3c/ServiceWorker/pull/1756 > > *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 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)? > Yes > > 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 about://flags > service-worker-auto-preload > > Finch feature name > ServiceWorkerAutoPreload > > Rollout plan > Will ship enabled for all users > > Requires code in //chrome? > False > > Tracking bug > https://crbug.com/40278676 > > Estimated milestones > > Shipping on desktop > 140 > Origin trial desktop first > 131 > Origin trial desktop last > 136 > DevTrial on desktop > 126 > Shipping on Android > 140 > Origin trial Android first > 131 > Origin trial Android last > 136 > DevTrial on Android > 126 > Shipping on WebView > 140 > > > Anticipated spec changes > > *Open questions about a feature may be a source of future web compat or > interop issues. Please list open issues (e.g. links to known github issues > in the project for the feature specification) whose resolution may > introduce web compat/interop risk (e.g., changing to naming or structure of > the API in a non-backward-compatible way).* > None > > Link to entry on the Chrome Platform Status > https://chromestatus.com/feature/5194817700364288?gate=6249384911306752 > > 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 > Intent to Experiment: > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGMyg-YF1qRNkBUPGxN-GgDGG3yvqCijZ56QEQYgNA4a9YrfMg%40mail.gmail.com > > > 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 visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGMyg-YGDFiHciHb701OhxBf3QUQbs-11o%2BjY03AAxvrrYmxow%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGMyg-YGDFiHciHb701OhxBf3QUQbs-11o%2BjY03AAxvrrYmxow%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- > 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 visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CH4PR00MB23298ED82DCB351D28A07555C559A%40CH4PR00MB2329.namprd00.prod.outlook.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CH4PR00MB23298ED82DCB351D28A07555C559A%40CH4PR00MB2329.namprd00.prod.outlook.com?utm_medium=email&utm_source=footer> > . > -- 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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPNB-6UDxXEjfHk%2BX-Om3tWNkpMgOMP_%3DbnSmjGjza8j3NU4zg%40mail.gmail.com.