Intent to Ship: ServiceWorkerAutoPreload

[Shunya Shishido]

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

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?

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.

[Daniel Clark]

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?

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, so I'm curious as to whether your thinking on that is still the same.

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 <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

--
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.

[Yoshisato Yanagisawa]

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.

 

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, 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.

 

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CH4PR00MB23298ED82DCB351D28A07555C559A%40CH4PR00MB2329.namprd00.prod.outlook.com.

[Shunya Shishido]

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.

 

 

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, 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 signal via the static routing API. In Chrome, based on the previous experiment result, 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.

[Yoshisato Yanagisawa]

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.

[Dan Clark]

Thanks for getting the spec PR landed, and for the clarifications on when the preload will be triggered. LGTM1.

-- Dan

[Yoav Weiss (@Shopify)]

LGTM2

[Mike Taylor]

LGTM3

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/51e15df7-ec66-4ad2-bb08-e69768444516n%40chromium.org.