Intent to Implement: Event Timing

[Liquan (Max) Gu]

Contact emails

ma...@chromium.org, tdre...@chromium.org

Design doc/Spec

WICG - Event Timing Web Perf API

Summary

The Event Timing API will enable web developers to measure event latency even early before the page load. It reuses the performance observer API and performance API to provide such ability.

Specifically, the API returns these information in its performance entries:

• event timestamp

• start of event processing time

• end of event processing time

Motivation

Monitoring event latency today requires an event listener. This precludes measuring event latency early in page load, and adds unnecessary performance overhead.

The API would allow:

1. Observe the queueing delay of input events before event handlers are registered.

2. Measure combined event handler duration.

Risks

Interoperability and Compatibility

Edge: No clear signal. Requested data from origin trial.

Firefox: No signals

Safari: No clear signal. Requested additional data, which we plan to gather via origin trial.

Web developers: No recorded feedback. Some positive response from earlier face to face discussions.

Ergonomics

The event timing have two major use cases:

• Buffer long latency UI events happening before onload.

• Observe long latency UI events with performance observers when users want to.

In order to get the buffered event timing entries before ‘onload’, one can do the following:

• performance.getEntriesByType(‘event’)

In order to observe the event with performance observer, one just needs to use performance observer to observe “event” entry type.

• new PerformanceObserver(callback).observe({ entryTypes: ['event'] });

Activation

Event Timing reuses the existing performance observer API and performance timeline API, so it would be easy for developers to adopt immediately.

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

Yes

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

This feature cannot be tested by web-platform-tests but can be tested by layout tests. One of the difficulty about testability in WPT is that JS cannot trigger events that are dispatchable with standard API. But we can simulate these events with GPU benchmarking extension.

We can test this feature as it was done for pointer events (example), where manual test are provided, and automated tests which automate these manual tests.

We can test the feature with these two scenarios:

• Onload happen before observer registration

• Onload happen after observer registration

Link to entry on the feature dashboard

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

Tracking bug

crbug/823744

Requesting approval to ship?

Not yet

[Dave Tapuska]

How does this API behave with the scenarios where the UA optimizes out not dispatching the events?

For example if you don't have a touch listener on the page at all you will never get TouchEvents dispatched to the document because the render process never actually sees them, then stay entirely on the browser side. Does adding a performance observer in this fashion actually decrease the optimizations that the UA can do?

Can the explainer be clarified about coalesced events as well? I presume you are only reporting the individual coalesced event which bias the coalesced events in reporting.

For example if I have a janky main thread then a series of key presses (> 50) will be reported individually, but a mouse moving will only have one event. So preparing a histogram of janky events might be biased.

dave.

--
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/CALKRbLaHV0TK1L759dO47pz2v47Owz16GfpEXBSCQ%2BkEtPmH9g%40mail.gmail.com.

[Timothy Dresser]

This API will only return input events which took more than 50ms between the event timestamp and the end of event processing.

If the events are not dispatched, the processing time will be < 50ms, and no entry will be dispatched.

Event coalescing takes place before we're producing JS event objects, so I think the explainer is fairly clear on this point. How do you think it could be misinterpreted?

You're right that coalescing could bias the set of events we report somewhat. Do you think this kind of bias is avoidable? Different types of events have different frequencies - I think this is inherent.

[Dave Tapuska]

> event coalescing....

The number of reported coalesced events could be a hint at jank as well. Note that when coalescing the event that is dispatched has the timestamp of the most recent event. So your reporting timing will likely be low for those continuous events because it isn't reporting age but freshness as currently spec'd.

I find the text in the following misleading then:

// Doesn't require an event listener of this type to be registered.

The other thing that isn't captured is the cost of the default event handler. Is it intended to capture that?

dave.

[Timothy Dresser]

Good point on coalesced events. We'll give that some thought.

The cost of the default event handler is covered. The current spec text around what used to be referred to as "default actions" now refers to "an operation which dispatches an event".

We record the timestamp when the operation dispatching the event begins, and measure until it ends. This includes the "default event handler" cost, and is why the API doesn't require an event listener of this type to be registered. If browser processing associated with the event is slow, we'll still dispatch an entry.