#670: InteractionID in Event Timing
Discussions
2022-05-23
Dan: the last time this was touched was Sept 2021.. it's been bumped. Somebody needs to look at this.
Rossen: still relevant?
Peter: it was an early review when it came it. Looks like it's been merged into their event timing spec a month after they opened it
Dan: it's in WebPerf [leaves comment]
OpenedAug 23, 2021
Ya ya yawm TAG!
I'm requesting a TAG review of InteractionID in Event Timing.
Currently, developers can measure the latency of an event using the Event Timing API. Developers may query the duration, which returns the next paint after event handlers have run. Or they may compute the input delay, the delta between startTime (the event's timeStamp) and processingStart, which is a timestamp taken right before event is dispatched. But measuring event latency separately can’t help developers fully understand the user’s pain. When a user interacts with a web page, a user interaction (i.e. click/tap, press a key, drag) usually triggers a sequence of events. For example, when the user clicks, several events will be dispatched: pointerdown, pointerup, mousedown, mouseup, click, etc. Therefore, we propose to measure the latency of the whole user interaction by aggregating associated events’ latencies. To calculate an interaction-level latency, there should be a way to group events or to tell if two events are fired by the same user interaction. We propose adding a new ID in PerformanceEventTiming named Interaction ID. Each Interaction ID will represent a unique user interaction. And events triggered by an interaction will share the same Interaction ID.
Further details:
You should also know that this feature is part of the larger project on a new responsiveness core web vital which improves upon first input delay, and we have published our current thoughts on a blog post.
We'd prefer the TAG provide feedback as (please delete all but the desired option): 💬 leave review feedback as a comment in this issue and @-notify @npm1