Intent to Implement: FetchEvent Worker Timing

[Ben Kelly]

Contact emails:

wande...@chromium.org

Explainer:

https://github.com/wanderview/fetchevent-worker-timing/blob/master/explainer.md

Design doc/Spec:

There is no formal spec beyond the explainer yet.  I plan to write that as part of the implementation.

I have requested an early TAG review:

https://github.com/w3ctag/design-reviews/issues/317

Summary:

This effort will expose an API on the `FetchEvent` dispatched within a service worker context that allows additional timing information to be associated with the intercepted network load.  This information will then be accessible in the main thread context on the resulting `PerformanceResourceTiming` entry.

Motivation:

Currently it is somewhat difficult for sites to measure the performance of service worker script that is executed while handling a FetchEvent.  The service worker script can take measurements, but there is no easy way to associate this data back to the original network request.  It requires an out-of-band communication mechanism like postMessage() or a server beacon with further data stitching to get a coherent view of the load.

The goal of this feature is to make it easier to measure and understand the performance of service worker FetchEvent processing on network loads.

Risks:

Interoperability and Compatibility:

This is a new feature that we plan to develop and standardize via incubation.  It will be feature detectable from both the service worker and main thread contexts.

Edge: No signals

Firefox: No signals

Safari: No signals

Web developers: Positive (multiple large sites and data analytics providers)

This proposal was presented to both the Service Worker and Web Performance working groups at TPAC this year.

Ergonomics

This feature is largely an integration of the service worker FetchEvent with the User Timing API.  It will become easier to use and more featureful when User Timing Level 3 ships.

Activation

Sites currently have custom systems to collect this data, but its difficult to build a generic polyfill currently.  Since the new data collected will be exposed in a fashion similar to the existing Server Timing API we hope it will be relatively straightforward for sites to integrate this new feature.

Debuggability

The entire objective of this feature is to make it easier for sites to understand the behavior of FetchEvent handling.  It should be relatively predictable and straightforward to work with the new API.  It could be integrated with the devtools network agent to display the information on each entry in the waterfall, but that would probably be a later enhancement.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

All platforms

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5671674456309760

Requesting approval to ship?

No

[Yoav Weiss]

Thanks for working on this. Would be exciting to see better RUM monitoring of SW activity!

--
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/CAK7rkMgXpkXY1hDVd%2Bj5JTPLUUZXERkmf8%2BRjyPRp8C050xiRA%40mail.gmail.com.