Intent to Ship: Event Timing
Nicolás Peña
Contact emails
Explainer
https://github.com/WICG/event-timing/blob/master/README.md
Spec
https://wicg.github.io/event-timing/
TAG review: https://github.com/w3ctag/design-reviews/issues/324
Summary
Chrome currently ships First Input Timing, i.e. ‘first-input’ entries. It enabled developers to compute first input delay in the wild by always dispatching timing information about the first input event among the ones described here. We intend to augment this by shipping full Event Timing: ‘event’ entries as well as performance.eventCounts. These allow for a larger set of events than those considered for first input. A ‘durationThreshold’ parameter can be used in the PerformanceObserver to specify the minimum duration desired for slow events. The PerformanceEventTiming entry has also been augmented with a target attribute to improve attribution, based on feedback. This attribute will also be made available in the first-input entry as part of this change.
This will enable developers to capture slow events as well as approximate percentiles of:
Input delay: time from input timestamp to time when input starts being processed.
Input sync processing time: time spent running all the event handlers for an event.
Input sync ‘duration’: time from input timestamp to next paint after handlers have run. This is the duration used to determine the slow events.
Link to “Intent to Prototype” blink-dev discussion
Link to Origin Trial feedback summary
EventTiming was available as an Origin Trial a while back. Some of the feedback we got was:
Some developers found the data very valuable (see Alibaba comments in the I2E).
Analytics providers found the data valuable but hard to use due to lack of attribution. This is why we added the ‘target’ attribute.
For some use-cases, input sync processing time is not good enough. However it’s hard or impossible to track causality. We have work in progress to enable developers to annotate their work to enable asynchronous event processing time tracking, but that will likely happen under User Timing or a different API instead.
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Debuggability
This can only be used via PerformanceObserver (not via Performance Timeline). That is, something like this will work on the console:
new PerformanceObserver(callback).observe({type: ‘event’, buffered: true, durationThreshold: 32});
Risks
Interoperability and Compatibility
We anticipate low compat risk but it’s not clear how much delay there would be until other major rendering engines ship this API. We’ve had discussions about this API several times in the WebPerf WG. Minutes from the last one here.
Edge: positive feedback from Todd Reifsteck, who unfortunately has moved on and is no longer part of the WebPerf WG. We currently do not have anyone from Edge attending our calls. More recently I asked for signals but did not get a response.
Firefox: some positive feedback during the calls. I requested a standards position but it is still open.
Safari: they’ve attended some of the calls but had no major feedback. Asked why it is separate from longtasks. They filed some editorial issues on the spec.
Web / Framework developers: positive feedback received from Alibaba (they were sad when the Origin Trial ended) and analytics providers like Akamai.
Ergonomics
It is used with PerformanceObserver, which uses a separate async task to dispatch entries.
Activation
It should not be challenging as web perf APIs do not require support in all browsers to be adoptable (inability to measure performance in unsupported browsers will not break the user experience). A polyfill could be useful if developers intend to gather data on browser vendors that do not implement Event Timing. There is a very old polyfill here. We will add documentation somewhere on https://web.dev/.
Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
https://wpt.fyi/results/event-timing?label=experimental&label=master&aligned
Entry on the feature dashboard
https://www.chromestatus.com/feature/5167290693713920
Yoav Weiss
--
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/ecb986ad-9308-47d4-bacb-573c0d4d053d%40chromium.org.
Chris Harrelson
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgufxHwYX3oNuS0FpBY-Da5XUYOz%3DDGH_mV3u7giiMpKg%40mail.gmail.com.
Daniel Bratell
LGTM3
/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw90-a%3D9Knmxi-qObd5suCqVBaeuwde%2Byh%2BOdGQQmR35zg%40mail.gmail.com.
Ilya Grigorik
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/32b5aa7d-2445-81be-2414-25dc6c38fe9f%40gmail.com.