Add service worker static routing API information to resource timing

[sisidovski]

Service Worker Static Routing API is the API that allows developers to selectively choose whether the ServiceWorker should intercept requests, and allow them to specify when to not run ServiceWorker. In addition, it allows the them to offload simple ServiceWorker operations like cache look up. i.e. they can return resources from CacheStorage without running ServiceWorkers.

The API was proposed in service-worker-static-routing-api, and it was merged into the SW spec in https://github.com/w3c/ServiceWorker/pull/1701 recently.

Service Worker provides timing information to mark certain points in time. However, it currently does not have any fields related to the ServiceWorker Static Routing API. Developers would benefit from having fields that provide information such as matched router info or taken time to evaluate the registered SW router.

For more details, please see the static routing API explainer for the resource timing here. https://github.com/WICG/service-worker-static-routing-api/blob/main/resource-timing-api.md

We appreciate any feedback from the community!

[nicjansma]

This was presented and discussed on the June 6th 2024 WebPerf WG call: minutes

Summary of some points in the discussion:

• fetchStart would be best aligned to responseStart (rather than 0) for compat issues
• Some of the questions/concerns here are similar to issues discussed in:
  • https://github.com/w3c/navigation-timing/issues/199
  • https://github.com/w3c/resource-timing/issues/363
• Can we prefix e.g. finalRouterSource with workerFinalRouterSource since the others are also prefixed?

The working group is aiming to schedule a follow-up meeting to align on all of the above.

[quasi-mod]

FYI, we’ve started the Chrome origin trial from M131 to add the proposed fields to resource timing api. If you are interested, please participate from the origin trial dashboard link. We would really appreciate your insightful feedback!

[quasi-mod]

@ErikWitt Thanks for providing us with feedback for SW static routing API! Based on your interest, I thought you might be interested in this Origin Trial as well. Let us know what you think.

[ErikWitt]

Thanks for the heads up. I share some first feedback and a question here

[davehunt]

Tracking Mozilla's position in https://github.com/mozilla/standards-positions/issues/1031

[quasi-mod]

FYI this feature has been launched and enabled by default in Chome 140.

[yoavweiss]

@sisidovski @quasi-mod - Are there any spec changes required from Resource Timing for this? Or were all the changes done in Service Workers?

[sisidovski]

@quasi-mod Can you check the current status? AFAIK these are all spec changes, and we don't need to change Resource Timing spec, correct?

• https://github.com/w3c/ServiceWorker/pull/1769
• https://github.com/whatwg/fetch/pull/1832

[yoavweiss]

• Add new fields and getter steps for static routing resource timing ServiceWorker#1769

I see the "service worker timing info" defined here, but I don't see where those timestamps are exposed..

[quasi-mod]

Thanks, we are still waiting for the fetch side spec to be reviewed (and might require support from other vendors as well?). (Just noticed that I hanged the fetch-side change dangling with a comment. Will send the change now)

[quasi-mod]

I see the "service worker timing info" defined here, but I don't see where those timestamps are exposed..

Let me check on this

[sisidovski]

Are we talking about this? https://w3c.github.io/ServiceWorker/#service-worker-timing-info

[yoavweiss]

Indeed

[yoshisatoyanagisawa]

It is actually an output of Handle Fetch, and plumbing in the fetch spec is https://github.com/whatwg/fetch/pull/1832.

[yoavweiss]

Yes, but I don't see an actual IDL that defines an API that exposes this to web developers. (the one implemented here)

[yoshisatoyanagisawa]

Yes, but I don't see an actual IDL that defines an API that exposes this to web developers. (the one implemented here)

I think https://github.com/w3c/resource-timing/pull/415/files has the IDL update.

[yoavweiss]

I think https://github.com/w3c/resource-timing/pull/415/files has the IDL update.

OK, cool. That's what I was missing.

[yoshisatoyanagisawa]

Upon https://issues.chromium.org/issues/448174607, we may also need to standardize the deliveryType change told in https://github.com/WICG/service-worker-static-routing-api/blob/main/resource-timing-api.md#deliverytype-when-final-router-source-is-from-cache Upon the WG request, Chromium has already been updated to show "cache-storage" deliveryType, but it confused the Web developer. I heard that @quasi-mod will send PR soon. Please stay tuned.