Event Timing

[yoavweiss]

WebKittens

@achristensen07, @rniwa

Title of the proposal

Event Timing

URL to the spec

https://www.w3.org/TR/event-timing/

URL to the spec's repository

https://github.com/w3c/event-timing

Issue Tracker URL

No response

Explainer URL

No response

TAG Design Review URL

w3ctag/design-reviews#324

Mozilla standards-positions issue URL

mozilla/standards-positions#283

WebKit Bugzilla URL

No response

Radar URL

No response

Description

This was previously discussed on the webkit-dev mailing list. I think it's worthwhile to revive that discussion, given that since then the feature:

• shipped in Firefox
• proved to be an essential building block for measuring responsiveness on the web.

[othermaciej]

From the previous discussion, it seems like the previous concerns were potential duplication/overlap with Long Tasks API, and imprecision of some definitions. Adding appropriate concern labels. (Perhaps those concerns are now addressed).

[othermaciej]

It looks like @rniwa ’s issue regarding imprecision may be addressed, I will let him comment whether there are still interop concerns w3c/event-timing#91

[rniwa]

The imprecise definition issue has been addressed but I don't think my concern for assistive technology interaction (some AT initiated user interaction wouldn't trigger pointerdown/up, mousedown/up, or keydown/up events) and single page app has been addressed. It's also questionable to assume that the very first user interaction is the only thing users care about.

A more clear model would be to always report input delays regardless of whether it was first or not. That'll make this API more useful with single page apps as well.

Also, the precision limit of 8ms should probably be gated on 120Hz rAF. In browsing context in which rAF happens at 60Hz, we should probably use 16ms precision instead to avoid exposing new information.

[yoavweiss]

Thanks!!

I don't think my concern for assistive technology interaction (some AT initiated user interaction wouldn't trigger pointerdown/up, mousedown/up, or keydown/up events)

Can you share more details or pointers to what events they do trigger? I don't necessarily have a correct mental model for such AT interactions.

and single page app

Single page app navigations are handled by https://github.com/WICG/soft-navigations
Event Timing would capture the navigation interaction in their case, but not any paints beyond that. Event Timing also does a great job at capturing interactions inside of Single Page Apps that don't result in navigations.

It's also questionable to assume that the very first user interaction is the only thing users care about.

I believe you're referring to the "first-input" entries. I don't think the specification assumes it's the only thing users care about, but it does split it out from other "event"-type entries.
The assumption is that for the very first interaction, there's value in surfacing it even if it's fast, and therefore the "first-input" entry has no duration threshold. That's contrary to other interactions (represented by the "event" entries) that are only surfaced if they are slower than a certain threshold. (104ms by default, unless explicitly reduced by the web developer, using the durationThreshold option)

A more clear model would be to always report input delays regardless of whether it was first or not. That'll make this API more useful with single page apps as well.

As I mentioned above, the main difference between “first-input” and “event” entries is that “event” entries are subject to a duration threshold. An initial concern with removing the duration threshold was that it may result in too many entries being emitted, where most of them are not of interest. If you think that we should reconsider this, it’s definitely something we could discuss.

Also, the precision limit of 8ms should probably be gated on 120Hz rAF. In browsing context in which rAF happens at 60Hz, we should probably use 16ms precision instead to avoid exposing new information.

It should be noted that there’s a in-flight plan to add a rAF-end-aligned paintTime attribute (based on w3c/paint-timing#108 that resolved w3c/paint-timing#62, and would be applicable here as well). Once EventTiming duration would align on it, no new information would be exposed.

But, if there’s demand for it, I'm sure the spec language can be modified to allow for coarser UA-defined precision for duration.