Bug 305251 – High INP (Interaction to Next Paint) for interactions with no immediate screen updates

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[Barry Pollard]

When I visit this simple demo page:
https://www.tunetheweb.com/experiments/event-timing/
and click on the `<h1>` I see PerformanceEventTiming entries (used to measure INP) of 504ms or more when it should be much closer to 150ms.

I even see it when there are no event handlers at all:
https://www.tunetheweb.com/experiments/event-timing/no-event-handlers.html

Curiously I don't often see it with this more complex page:
https://chrome.dev/inp-demo/
That has a widget causing constant frame updates - Maybe that is why?

So here's a copy of my origin demo that does a screen update:
https://www.tunetheweb.com/experiments/event-timing/with-update.html
And now pointerup/click is as expected, and usually too fast to even register (except for the first first-input).

We still see a somewhat slow pointerdown, so let's add an event handler to that:
https://www.tunetheweb.com/experiments/event-timing/with-both-updates.html
And now that's also fixed.

If there is no screen update to make, then `first-input` and `event` should return quickly/almost instantly rather than appear to show a poor responsiveness. I can't see this explicitly mentioned in the spec (https://w3c.github.io/event-timing/#sec-performance-event-timing) but it's how Chrome and Firefox work.

[Alexey Proskuryakov]

Thank you for the report!

[Radar WebKit Bug Importer]

<rdar://problem/168016487>

[Franco Vieira de Souza]

Pull request: https://github.com/WebKit/WebKit/pull/56574

[EWS]

Committed 306142@main (8af8a7cdd78d): <https://commits.webkit.org/306142@main>

Reviewed commits have been landed. Closing PR #56574 and removing active labels.