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 w3c/ServiceWorker#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:
  • Timing values are inconsistent across browsers when page is controlled by service worker navigation-timing#199
  • How to get correct connectStart/End, domainLookupStart/End value when service worker is enabled? #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.