2025年7月28日(月) 13:05 Shunya Shishido <sisidov...@chromium.org>:
> > > On Fri, Jul 25, 2025 at 2:37 PM Yoshisato Yanagisawa < > yyanagis...@chromium.org> wrote: > >> >> >> 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. >> > Comments were resolved, I believe now it's ready to be landed. > > Thank you. LGTM, merged. > >> >>> 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. >> > Yes. The spec says that a user agent may dispatch a network request unless > there is an opt-out > <https://github.com/WICG/service-worker-auto-preload?tab=readme-ov-file#opt-out> > signal via the static routing API. In Chrome, based on the previous > experiment result > <https://github.com/WICG/service-worker-auto-preload/issues/3>, we'll > enable this optimization when the service worker is not running. In the > future, we may want to implement another criteria such as higher rates of > fetch handler results are fallback for further optimization. > > >> >> >>> 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? >>> >> Again we'll enable this when the service worker is not running. For the > fetch handler fallback rate, we don't have this mechanism yet, and we need > another study to determine the threshold. But we believe it's worth > exploring in the future since there are so many sites using service workers > and the main resource fetch handler results are always fallback. > > Have you talked to the WebKit folks to see what eligibility criteria they >>> plan to use for their version of the feature? >>> >> Yes. I understand their criteria is also when the service worker is not > running. Please check this comment > <https://github.com/WICG/proposals/issues/155#issuecomment-2873318636>. > > >> >>> -- 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-6VByS6LpsO8RitjXXS18Be7CQ5vhb0V0fXLNAxNw%2BrDDg%40mail.gmail.com.
