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. > > >> 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/CAGMyg-b4E%2B%3DkN4w2bhnBJO4%2BQyfqoexPwUa6-OHDNy4kAiOT8A%40mail.gmail.com.
