Developers currently use the Event Timing API to gather performance data about events they care about. However, it is currently hard to link events that correspond to the same user interaction. For instance, when a user taps, many events are generated, such as pointerdown, mousedown, pointerup, mouseup, and click. The interactionID enables developers to link multiple PerformanceEventTiming entries when they correspond to the same user interaction.
Motivation
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.
Specification
Specification being incubated in a Community Group
Status in Chromium
Enabled by default
(tracking bug)
Consensus & Standardization
Owners
Last updated on 2022-01-04