docs/speed/metrics_changelog/2026_02_inp.md
In Chrome 147, Chrome overhauled how interaction IDs are assigned in the Event Timing API, reduced reporting latency, and thus improved Event Timing reporting rates.
Previously, interaction IDs were generated and associated with PerformanceEventTiming entries asynchronously only after the presentation time of the next paint was available, and full duration value of the Event Timing was known. I.e., measure timing first, assign Interaction status last.
In general this ordering didn't matter much, since we couldn't report the entry until both interaction status and final duration were available.
However, some event types, such as pointerdown and keydown, needed to wait for pointerup or keyup events to arrive before a full interaction could be identified, and they were waiting needlessly long. Additionally, the previous behaviour could lead to a different event ordering for interaction id assignment, relative to original main thread event dispatch. This led to needlessly complex internal state machine processing.
Starting in Chrome 147, interaction IDs are assigned synchronously at processingStart as soon as event dispatch begins on the main thread. This decouples interaction ID generation from asynchronous presentation timing, ensuring all event parts of an interaction share the same ID reliably and in chronological order. This was mostly an internal simplification, but did potentially fix interactionID assignment in some rare edge cases.
This work was needed to support interaction-contentful-paint.
Alongside early ID assignment, Chrome removed renderer-side UKM buffering. Previously, the renderer buffered Event Timing data to identify and report only the single longest event per interaction ("whole interaction / max event duration"). In Chrome 147, the renderer reports "each event" (every part of every interaction) directly to the browser process, where PageLoadMetricsObserver handles aggregation for PageLoad UKM.
This eliminates complex renderer timers, data structures, and flushing logic upon page unload.
Importantly, this reduces the risk of dropping very late interaction data during page abandonment, such as when a user clicks a link that immediately navigates away, especially on pages with only a single interaction.
The implementation change can be seen in crrev.com/c/7596544.
pointerdown, pointerup, click, keydown, keyup) using interactionId with a few less edge-case ID mismatches during rapid user input.When a user right-clicks or triggers a context menu, the operating system / browser native context menu UI can take focus and interrupt regular web page rendering.
Previously, Chrome relied on timer-based flushes to finalize the duration of preceding input events when a context menu appeared. If main-thread or system scheduling delayed the timer, the interaction could report an artificially inflated duration.
Chrome 147 introduces an explicit fallback mechanism that immediately resolves the end time of preceding interaction events upon contextmenu dispatch.
The source change can be found in crrev.com/c/7588183.
Chrome 147 reached stable users in February 2026.