Interaction to Next Paint Changes in Chrome 129

Enable ContinueEventTimingRecordingWhenBufferIsFull by default

On any page that does not register a PerformanceObserver for the Event Timing API, there is a limited number of event timings stored into the default performance timeline buffer (similar to many other performance entries). Currently that number is 150 entries, each of which would be over 100ms in duration.

Previously: When this buffer filled up, tracing and UKM reporting would also be stopped as a consequence.

Now: We ensure that all events are always measured, even if the performance timeline entry is dropped when the buffer is full.

Note: this experiment was first landed in Chrome 126: Remove event timing instantiation condition , and was slowly rolled out.

How does this affect a site's metrics?

Sites might be affected under the following conditions:

The site was not already using a PerformanceObserver to measure Event Timing. The site was already running out of space in the default event timing buffer -- typically only true for very long lived and interactive sites. On such sites, now that even more interactions are now being measured, it's possible that a very late interaction is slower than a very early interaction, and thus now reporting longer INP durations. This is not common.

Further, on some sites, the buffer could fill up with lots of Event Timings, before the first discrete user interaction. This meant that the page might not report any INP score before, and now it will do so. This is also not common, but might happen especially on desktop devices with mouse input, where pointer movements might trigger lots of “hover” events.

When were users affected?

Launch was the week of Sept 17, 2024, when m129 was in stable, but a limited number of early adopters might have seen this change as early as m126.