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.

Reply via email to