This feature is to report all interactions a user has with a webpage that are still in the middle of measurement right before the page closes or becomes hidden, at the page visibility change time. The situation is most common when the final interaction navigates the page away before next paint.
As a result, a registered PerformanceObserver might not have time to call the observer callback with the final entries, but web developer can use .takeRecords() to synchronously read the final values.
Note: this experiment was first landed in Chrome 128: Reland “Flush event timings at visibility change”, and was slowly rolled out.
Some sites will now report more interactions per pageload. In particular, some pages which did not have a chance to report even a single interaction (because document unloaded too quickly), might now report 1 interaction. While we did not see statistically significant movements to INP scores with this change, we did see increased reporting coverage for the INP metric.
Launch was the week of Oct 21, 2024, when m130 was in stable, but a limited number of early adopters might have seen this change as early as m128.
A click event could be emitted if input elements (such as buttons, checkboxes, radio), as well as links, etc are interacted by keyboard actions. Currently such click events have a different interaction id with that of the keydown, keypress, and keyup events.
This feature is to add special handling to make the click event's interaction id to be the same as that of other associated keyboard events.
Note: this experiment was first landed in Chrome 129: Add special handling for keyboard triggered clicks, and was slowly rolled out.
No statistically significant movements to INP is observed, which is expected as this feature only adjusts which interactionId a keyboard-click event gets. It might have potentially moved NumInteractions by a minimal amount since we will now group click with key events instead of creating a separate interactionId for it. We see some minimal effect that this happened on desktop platforms only, which is also expected.
Launch was the week of Oct 21, 2024, when m130 was in stable, but a limited number of early adopters might have seen this change as early as m129.
This experiment excludes taps and clicks which stop a fling scroll from INP measurement.
During an active fling, a tap or a click can make it stop, but these events are not the same as a normal tap or click. For example, the pointerdown and pointerup events are fired but no click events are fired, default user agent actions aren’t triggered on the elements (i.e. links and buttons don't get clicked). More importantly, these interactions occur in the middle of an active scroll and the first visual feedback that the user receives is that the scroll stops. That “scroll stop” animation frame is entirely driven by the compositor and is not the next paint as measured by INP. It is also problematic to measure the events with the scroll animation.
Note: this experiment was first landed in Chrome 129: Don't set interaction ids to the input events when the scroll is active, and was slowly rolled out.
This affects the INP metrics mainly on Android which uses touch screens.
On Android (where touch driven scroll fling is a common gesture), we observed a slight decrease in the number of INP events recorded, due to a small number of page loads having only fling stops as the only interaction. These page loads no longer report INP. We also observed a slight decrease in INP at the 95th and 99th percentiles. Some sites may see a small reduction in the number of page loads where INP is recorded, and a slight decrease in INP overall.
Launch was the week of Oct 21, 2024, when m130 was in stable, but a limited number of early adopters might have seen this change as early as m129.
