LGTM2 On Tuesday, July 29, 2025 at 2:01:24 AM UTC+2 dan...@microsoft.com wrote:
> Thanks for getting the spec PR landed, and for the clarifications on when > the preload will be triggered. LGTM1. > > -- Dan > > On Sunday, July 27, 2025 at 10:06:56 PM UTC-7 yyana...@chromium.org wrote: > >> >> >> 2025年7月28日(月) 13:05 Shunya Shishido <sisid...@chromium.org>: >> >>> >>> >>> On Fri, Jul 25, 2025 at 2:37 PM Yoshisato Yanagisawa < >>> yyana...@chromium.org> wrote: >>> >>>> >>>> >>>> 2025年7月25日(金) 10:44 'Daniel Clark' via blink-dev <blin...@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 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 <sisid...@chromium.org> >>>>> >>>> >>>>> *Sent:* Wednesday, July 23, 2025 12:54 AM >>>>> >>>> *To:* blink-dev <blin...@chromium.org> >>>>> >>>> >>>>> *Subject:* [EXTERNAL] [blink-dev] Intent to Ship: >>>>> ServiceWorkerAutoPreload >>>>> >>>> >>>>> You don't often get email from sisid...@chromium.org. Learn why this >>>>> is important <https://aka.ms/LearnAboutSenderIdentification> >>>>> Contact emails >>>>> sisid...@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+...@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+...@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/51e15df7-ec66-4ad2-bb08-e69768444516n%40chromium.org.
