Interaction to Next Paint Changes in Chrome 133

Enable EventTimingSelectionAutoScrollNoInteractionId by default

Typically, highlighting text on a page with a pointing device does count as an interaction, will get reported with interactionID and will count towards INP.

This is because long tasks on the page will prevent the highlighted area from updating, and a site will certainly feel unresponsive to users.

At the moment, Event Timing will only measure the first pointerdown, and final pointerup, gestures of these types of interactions. Pointermove events in the middle, although they might update highlighted area and may feel slow, are never measured.

This feature which is launching updates one specific use case we learned should not warrant being labelled an Event Timing interaction: when the highlighted area goes beyond the viewport boundary, and updates force the page to scroll automatically. At this point, this becomes a “scrolling” interaction, which Event Timing ignores under typical flows.

Although technically still a pointer interaction, and although highlighted area is still being updated, Scrolling has very different characteristics than other interactions:

• Smoothness and consistency across many animation frames, rather than responsiveness of a single frame, matter more
• Scrolling is typically driven by the compositor thread, without the need for main thread scheduling. The “default action” of scrolling produces a “next paint” before the event is dispatched and measured by Event Timing. Thus even a slow event timing might still feel fast to the user because of the immediate scroll offset update.
• Finally, at scroll end many effects might trigger, such as intersection observers or lazy loaded content, which can slow down the pointerup event.

Note: this experiment was first landed in Chrome 132: Reland “Flush event timings at visibility change”, and was slowly rolled out.

How does this affect a site's metrics?

In practice, it shouldn't affect most sites at all. Most sites will never even have a chance to be affected by this change, and for those that might, it is unlikely to affect your high percentile field data.

However, for the few sites which have the following patterns:

• Users are often highlighting enough text to scroll the page (i.e. perhaps on desktop devices, with long articles)
• Effects trigger during scroll or after stop (i.e. scroll linked animations, which require main thread, or intersection observers + lazy loaded content)
• Long tasks that trigger from these effects

Under criteria such as these, you might have a long interaction triggered by a pointerup event which also immediately stop the scroll of the page.

When were users affected?

Launch was the week of Feb 27, 2025, when m133 was in stable, but a limited number of early adopters might have seen this change as early as m132.