#670: InteractionID in Event Timing

Visit on Github.

Opened Aug 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.

  • Explainer¹ (minimally containing user needs and example code): url
  • Security and Privacy self-review²: url
  • Primary contacts (and their relationship to the specification):
    • Nicolás Peña Moreno (@npm1, Google)
    • Hongbo Song (@debugtive0517, Google)
  • Organization/project driving the design: Google
  • External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): Chromium impl bug

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
  • The group where standardization of this work is intended to be done ("unknown" if not known): W3C Web Perf
  • Existing major pieces of multi-stakeholder review or discussion of this design: this was presented to the WebPerf WG, see minutes
  • Major unresolved issues with or opposition to this design: N/A
  • This work is being funded by: Google

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

Discussions

2022-05-23

Minutes

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]

2022-08-15

Minutes

closed as timed out