Events measured by Event Timing typically measure to Next Paint (and its presentation time). But sometimes we don't need a next paint, and can end measurement immediately at processingEnd.
This detail come sometimes lead to multiple distinct events overlapping in time in non-intuitive ways. As one example:
Let's say and event (A) arrives first, and requires next paint. It will measure:
Because waiting for Presentation delay is not blocking the main thread, another event (B) might arrive next. If Event B does not require next paint, it will only measure:
Input delay (for Event B) Processing Duration (for Event B) Now, even thought Event B arrived after Event A, its performance Event Timing measurement might be completed first... whenever we‘re still waiting to receive Event A’s presentation time.
In such cases, even though performance measurement for Event B “wraps up” first, we cannot assume that Event B actually ends first. This is because it takes time to schedule the feedback of a presentation time, which is itself an asynchronous process. And even when the measurement accounting work for Event B is available first, once we read the presentation time value for Event A, it might have actually been first.
Previously, whenever this happened, we would flush all event timings and assign the current time as the end time to all these events, even those waiting for the next paint presentation time. Now, we will wait until the correct next paint presentation time actually arrives for those events.
Note: this experiment was first landed in Chrome 114: Event Timing Presentation Promise Handling Redesign, but was rolled out slowly.
This change improves the quality/accuracy of INP, but its impact on a specific site is unpredictable and can be different case by case depending on use cases. In general, we saw a overall decrease on INP on mobile and an increase on INP on desktop.
Chrome 122 was released the week of February 20, 2024.
