ServiceWorkerAutoPreload #1756

sisidovski · 2025-03-03T07:20:29Z

This is the PR to support ServiceWorkerAutoPreload.

ServiceWorkerAutoPreload is defined as an optional browser optimization so that the browser minimizes the cost of the bootstrap by dispatching the navigational network request before starting the service worker. The dispatched network request is consumed by fetch(e.request) in the fetch handler after the bootstrap, or consumed by the client as a fallback request if the fetch handler doesn't call respondWith().

The developer can disable this optimization by opting out via setting the router rule provided by the static routing API. Specifically, the router source "network" works as an opt-out signal.

Please read the explainer for more detail.

Preview | Diff

sisidovski · 2025-06-16T00:12:42Z

@yoshisatoyanagisawa @youennf I think now it's ready for the review. Could you take a look? Thank you!

docs/index.bs

yoshisatoyanagisawa · 2025-06-16T06:38:06Z

docs/index.bs

-          1. [=If aborted=], then:
-              1. Let |deserializedError| be the result of [=deserialize a serialized abort reason=] given null and |workerRealm|.
-              1. [=fetch controller/Abort=] |preloadFetchController| with |deserializedError|.
+      1. If |request| is a [=navigation request=], |request|'s [=request/method=] is \`<code>GET</code>\`, |registration|'s [=active worker=]'s [=set of event types to handle=] [=set/contains=] <code>fetch</code>, and |registration|'s [=active worker=]'s [=all fetch listeners are empty flag=] is not set then:


Ah, you explicitly skip subresource auto preload. just for note to myself.
https://github.com/WICG/service-worker-auto-preload?tab=readme-ov-file#auto-preload-for-subresources

yoshisatoyanagisawa · 2025-06-16T07:02:55Z

No need to do that in this PR, but I feel steps to create |raceResponse| can be merged with "race-network-and-fetch-event" case.

sisidovski · 2025-06-17T06:27:37Z

docs/index.bs

+              1. [=If aborted=], then:
+                  1. Let |deserializedError| be the result of [=deserialize a serialized abort reason=] given null and |workerRealm|.
+                  1. [=fetch controller/Abort=] |preloadFetchController| with |deserializedError|.
+          1. Else if |timingInfo|'s [=service worker timing info/worker matched router source=] is not "{{RouterSourceEnum/fetch-event}}", a user agent may run the following substeps:


Updated not to introduce |source| here, use |timingInfo|'s [=service worker timing info/worker matched router source=] instead.

Why doing autopreload if the route is NOT fetch-event?
I would expect to only do autopreload if the route is actually fetch-event.

We frame the autopreload is an optional optimization that the browser can apply at its choosing. So we want to use the static routing API as an opt-out mechanism. If we only invoke the autopreload only when the matched router source is fetch-event, that is more like an opt-in, not opt-out.

Ah I see, I was mislead thinking that, at this point, the source could be other values like cache and so on, but it can only be null or fetch-event really.

Maybe, it would be clearer if we would check if worker matched router source is null?

Thank you! That sounds reasonable. Added Assert: [=service worker timing info/worker matched router source=] is null..

yoshisatoyanagisawa

lgtm.

yoshisatoyanagisawa · 2025-06-18T02:21:27Z

The specification change itself looks good to me. However, let me wait for other vendors to agree the change.

youennf

Looks ok overall to me, some thoughts inline

youennf · 2025-06-18T09:56:20Z

docs/index.bs

+              1. [=If aborted=], then:
+                  1. Let |deserializedError| be the result of [=deserialize a serialized abort reason=] given null and |workerRealm|.
+                  1. [=fetch controller/Abort=] |preloadFetchController| with |deserializedError|.
+          1. Else if |timingInfo|'s [=service worker timing info/worker matched router source=] is not "{{RouterSourceEnum/fetch-event}}", a user agent may run the following substeps:


Why doing autopreload if the route is NOT fetch-event?
I would expect to only do autopreload if the route is actually fetch-event.

youennf · 2025-06-18T09:57:50Z

docs/index.bs

+                  1. [=fetch controller/Abort=] |preloadFetchController| with |deserializedError|.
+          1. Else if |timingInfo|'s [=service worker timing info/worker matched router source=] is not "{{RouterSourceEnum/fetch-event}}", a user agent may run the following substeps:
+
+              Note: A user agent may speculatively dispatch a network request in parallel with creating a fetch event in order to minimize the bootstrap cost.


Is there sufficient description on when to do this speculative load?

In the explainer, we mention two possible scenarios that the browser may invoke the autopreload.
https://github.com/WICG/service-worker-auto-preload?tab=readme-ov-file#eligibility-criteria

I don't think we can fully specify when it's used since some conditions are not deterministic, but do you think we should say more here?

That might be ok as is. If there are cases where all browsers plan to do autopreload, we could be more precise, maybe with a SHOULD for instance. Say if the service worker is not running?

Yes. Let's keep it as is for now.

Just to note: we're happy with rephrasing it with SHOULD.

youennf · 2025-06-18T10:03:37Z

docs/index.bs

+              1. Set |responseForAutoPreload| to be a [=race response=] whose [=race response/value=] is "<code>pending</code>".
+              1. Run the following substeps [=in parallel=], but [=abort when=] |fetchController|'s [=fetch controller/state=] is "<code>terminated</code>" or "<code>aborted</code>":
+                  1. Set |autoPreloadFetchController| to the result of calling [=fetch=] given |request|, with [=fetch/processResponse=] set to the following steps given a [=/response=] |autoPreloadRequestResponse|:
+                  1. If |autoPreloadRequestResponse|'s [=response/status=] is [=ok status=], set |responseForAutoPreload|'s [=race response/value=] to |autoPreloadRequestResponse|.


Why only using the auto preload response if it is a 2XX response?
What happens if the auto preload response is not a 2XX (I haven't yet looked precisely at how the race response mechanism works)?

Ah, good catch!
I guess |autoPreloadRequestResponse| should be set to |responseForAutoPreload|'s value regardless of the response status. Otherwise, deadlock at Step 21-3 in https://w3c.github.io/ServiceWorker/#create-fetch-event-and-dispatch-algorithm

Thanks! Updated to set the response to responseForAutoPreload regardless of the status.

docs/index.bs

sisidovski · 2025-07-07T06:54:50Z

@youennf Could you take a look this again? Thanks!

youennf · 2025-07-07T08:20:29Z

LGTM overall. Two suggestions as detailed in the comments, but they are not blockers.

sisidovski

Thanks!

sisidovski · 2025-07-07T08:43:00Z

docs/index.bs

+              1. [=If aborted=], then:
+                  1. Let |deserializedError| be the result of [=deserialize a serialized abort reason=] given null and |workerRealm|.
+                  1. [=fetch controller/Abort=] |preloadFetchController| with |deserializedError|.
+          1. Else if |timingInfo|'s [=service worker timing info/worker matched router source=] is not "{{RouterSourceEnum/fetch-event}}", a user agent may run the following substeps:


Thank you! That sounds reasonable. Added Assert: [=service worker timing info/worker matched router source=] is null..

sisidovski · 2025-07-07T08:46:44Z

docs/index.bs

+                  1. [=fetch controller/Abort=] |preloadFetchController| with |deserializedError|.
+          1. Else if |timingInfo|'s [=service worker timing info/worker matched router source=] is not "{{RouterSourceEnum/fetch-event}}", a user agent may run the following substeps:
+
+              Note: A user agent may speculatively dispatch a network request in parallel with creating a fetch event in order to minimize the bootstrap cost.


Yes. Let's keep it as is for now.

Just to note: we're happy with rephrasing it with SHOULD.

docs/index.bs

yoshisatoyanagisawa · 2025-07-28T05:03:26Z

ok, I think all comments are addressed.

SHA: 991cb02 Reason: push, by yoshisatoyanagisawa Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

SHA: 991cb02 Reason: push, by pull[bot] Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

sisidovski mentioned this pull request Mar 3, 2025

Chrome experiment result and standardization WICG/service-worker-auto-preload#3

Open

sisidovski mentioned this pull request Mar 11, 2025

ServiceWorkerAutoPreload WICG/proposals#155

Closed

sisidovski added 2 commits June 10, 2025 16:13

Support ServiceWorkerAutoPreload behavior

33123c4

Add opt-out condition

dd2b26b

sisidovski force-pushed the autopreload branch from 53e78bf to dd2b26b Compare June 10, 2025 07:29

sisidovski changed the title ~~[WIP] ServiceWorkerAutoPreload~~ ServiceWorkerAutoPreload Jun 10, 2025

sisidovski mentioned this pull request Jun 10, 2025

ServiceWorkerAutoPreload w3ctag/design-reviews#1108

Open

1 task

Merge branch 'w3c:main' into autopreload

3a53414

yoshisatoyanagisawa reviewed Jun 16, 2025

View reviewed changes

docs/index.bs Outdated Show resolved Hide resolved

yoshisatoyanagisawa reviewed Jun 16, 2025

View reviewed changes

sisidovski added 4 commits June 17, 2025 10:55

Move raceResponse to narrow down the scope

b1f4c5a

Restore raceResponse

89fdc14

Rename raceResponse to responseForAutoPreload

06eeb47

Remove |source|

d436dce

sisidovski commented Jun 17, 2025

View reviewed changes

yoshisatoyanagisawa approved these changes Jun 18, 2025

View reviewed changes

youennf reviewed Jun 18, 2025

View reviewed changes

Set the response to responseForAutoPreload regardless of the status

c2070a7

Add null assertion

74b9dc4

sisidovski commented Jul 7, 2025

View reviewed changes

yoshisatoyanagisawa reviewed Jul 8, 2025

View reviewed changes

docs/index.bs Outdated Show resolved Hide resolved

yoshisatoyanagisawa reviewed Jul 8, 2025

View reviewed changes

docs/index.bs Outdated Show resolved Hide resolved

Add timingInfo, intent

3daef71

yoshisatoyanagisawa merged commit 991cb02 into w3c:main Jul 28, 2025
2 checks passed

github-actions bot added a commit that referenced this pull request Jul 28, 2025

ServiceWorkerAutoPreload (#1756)

3274a8c

SHA: 991cb02 Reason: push, by yoshisatoyanagisawa Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

sisidovski deleted the autopreload branch July 28, 2025 06:36

github-actions bot added a commit to asleekgeek/ServiceWorker that referenced this pull request Jul 28, 2025

ServiceWorkerAutoPreload (w3c#1756)

860dfaa

SHA: 991cb02 Reason: push, by pull[bot] Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

ServiceWorkerAutoPreload #1756

ServiceWorkerAutoPreload #1756

Uh oh!

Conversation

sisidovski commented Mar 3, 2025 • edited by pr-preview bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sisidovski commented Jun 16, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yoshisatoyanagisawa commented Jun 16, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yoshisatoyanagisawa left a comment

Choose a reason for hiding this comment

Uh oh!

yoshisatoyanagisawa commented Jun 18, 2025

Uh oh!

youennf left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

sisidovski commented Jul 7, 2025

Uh oh!

youennf commented Jul 7, 2025

Uh oh!

sisidovski left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

yoshisatoyanagisawa commented Jul 28, 2025

Uh oh!

Uh oh!

Uh oh!

sisidovski commented Mar 3, 2025 •

edited by pr-preview bot

Loading