Intent to Prototype: Timing information for ServiceWorker Static routing API

122 views
Skip to first unread message

Keita Suzuki

unread,
May 20, 2024, 7:00:26 AMMay 20
to blin...@chromium.org

Contact emails

suzuk...@chromium.org, yyana...@chromium.org


Explainer

https://github.com/WICG/service-worker-static-routing-api/blob/main/resource-timing-api.md


Specification

None


Summary

Adds timing information for ServiceWorker Static Routing API, exposed in navigation timing API and resource timing API for developer use.


Service Worker provides timing information to mark certain points in time. We add two ServiceWorker Static Routing API-relevant timing information: workerRouterEvaluationStart, time to start matching a request with registered router rules, and workerCacheLookupStart, time to start looking up the cache storage if the source is "cache". In addition, we also add two router source information, the matched router source and the final router source.



Blink component

Blink>ServiceWorker


Motivation

Service Worker provides timing information to mark certain points in time. This is exposed and used by the navigation timing API as well as the resource timing API. It currently records two times:


- Start time

- Fetch event dispatch 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:


- the matched route (the route that the Static Routing API evaluated)

- the actual source from which the resource was retrieved

- the time it took to match the route

- the time to look up the cache for the cache source


This information will allow developers to measure the latency incurred by the API such as router evaluation time or time required to conduct cache lookup, or determine if the matched source is the final source used (can find out if the matched source failed to get the resource or not, and which source was used as the alternative).



Initial public proposal

https://github.com/w3c/resource-timing/issues/389


TAG review

None


TAG review status

Pending


Risks



Interoperability and Compatibility

The original ServiceWorker static routing API has received positive signals from Firefox, WebKit and Web developers. We are planning to start requesting signals for the timing information addition soon.


There are no compatibility risks, as this proposal only adds new fields to the timing information and will not modify any of the existing fields.


Gecko: No signal


WebKit: No signal


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

None



Is this feature fully tested by web-platform-tests?

We have an in-flight CL which adds wpt tests.(link)


Flag name on chrome://flags

None


Finch feature name

ServiceWorkerStaticRouterTimingInfo


Non-finch justification

None


Requires code in //chrome?

False


Tracking bug

https://crbug.com/41496865


Estimated milestones

No milestones specified



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6309742380318720?gate=6008560617259008


This intent message was generated by Chrome Platform Status.


Jonathan Hao

unread,
May 28, 2024, 10:23:26 AMMay 28
to blink-dev, Keita Suzuki
Please make sure that this new timing info abide by the Web Platform Security Guildeline: 
https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/web-platform-security-guidelines.md#timer-resolution

Keita Suzuki

unread,
Jun 3, 2024, 10:22:54 PM (12 days ago) Jun 3
to Jonathan Hao, blin...@chromium.org
Sorry. Forgot to CC blink-dev@, Let me resend the reply.

Thanks so much for the input.


> Please make sure that this new timing info abide by the Web Platform Security Guildeline:
> https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/web-platform-security-guidelines.md#timer-resolution

Our plan is to align the implementation with the existing resource timing implementation,
which already abides by the security guideline.

Yoshisato Yanagisawa

unread,
Jun 3, 2024, 11:42:39 PM (12 days ago) Jun 3
to Keita Suzuki, Jonathan Hao, blin...@chromium.org

2024年6月4日(火) 11:22 Keita Suzuki <suzuk...@chromium.org>:
Sorry. Forgot to CC blink-dev@, Let me resend the reply.

Thanks so much for the input.

> Please make sure that this new timing info abide by the Web Platform Security Guildeline:
> https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/web-platform-security-guidelines.md#timer-resolution

Our plan is to align the implementation with the existing resource timing implementation,
which already abides by the security guideline.

To be clear, we aim to use Performance::MonotonicTimeToDOMHighResTimeStamp as others do.
It uses ClampTimeResolution inside, and that should meet Jonathan's request.
 
--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFXMW93NNjJXsaEvZXNCaZC5p23ZqxFF7XYSzyOXOfGjxZZiPg%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages