Plenty of sites that score well on loading speed still fail Core Web Vitals, and the reason is usually the metric that gets the least attention. Interaction to Next Paint measures something the older tests did not, and it is unforgiving of a specific kind of sloppiness that never showed up before.
The three metrics, and the numbers that matter
According to Google's own documentation, the current Core Web Vitals and their "good" thresholds are:
- Largest Contentful Paint (LCP) — loading. Good is 2.5 seconds or under
- Interaction to Next Paint (INP) — responsiveness. Good is 200 milliseconds or under
- Cumulative Layout Shift (CLS) — visual stability. Good is 0.1 or under
The detail almost everyone misses sits underneath those numbers. Google assesses them at the 75th percentile of page loads, split between mobile and desktop. Your typical visit is not what is being graded. The slowest quarter of your real audience is — which on most sites means older phones on patchy connections, not the developer's laptop on office fibre.
What changed when INP replaced First Input Delay
INP became a stable Core Web Vital in 2024, taking over from First Input Delay. That was not a rename. The two measure genuinely different things, and the swap made the test considerably harder to pass.
First Input Delay only looked at the first interaction on the page, and only at the delay before the browser started responding. A site could pass by being quick off the mark once and sluggish forever afterwards.
INP watches every click, tap and keypress for the whole visit, and measures each one all the way through to the next frame actually appearing on screen. Not "did we start handling it" — "did the user see something change".
The three phases, and why the last one catches people out
Google breaks each interaction into three parts:
- Input delay — time before your event handlers begin running, usually because the main thread is already busy with something else
- Processing duration — time for your handler code to run
- Presentation delay — time from your code finishing until the next frame is painted
Most optimisation effort goes into the middle one, because that is the part that looks like "your code". Teams profile their handlers, make them faster, and are surprised when the score barely moves.
The other two are frequently the larger share. Input delay is not caused by the interaction at all — it is caused by whatever was already running. And presentation delay is dominated by how much work the browser has to do to draw the result: large or complex layouts, layout thrashing, expensive style recalculation, an oversized DOM, and rendering HTML on the client.
That last list is worth reading twice, because none of those items is a slow event handler. You can write perfect handler code and still fail.
A concrete example from our own site
While instrumenting our 3D gallery this month, we found a wheel event listener that had been registered permanently, was marked non-passive, and whose handler body did nothing at all.
An empty function is free to run. The cost was elsewhere: marking a listener non-passive tells the browser that the handler might cancel the default scroll, so the browser cannot begin scrolling until the handler has finished. Every wheel event was being routed through the main thread and waited on, to run a function that did nothing.
That is a textbook input-delay problem, and it is invisible in a profiler that only shows you where time is spent inside your own functions — because no time was being spent there. We fixed it by registering the listener only while the lightbox is actually open. Nothing about the handler changed; only when it exists.
The general lesson: look for work the browser is forced to wait on, not just work that is slow. Non-passive scroll and touch listeners are the most common example, and a great many of them are attached by third-party scripts nobody has audited.
Where to actually start
Google's own recommended order is field data first, lab testing second — find which real interactions are slow before diagnosing why. That ordering matters more than it sounds. Lab tools tell you what could be slow on a simulated device; field data tells you what is slow for the people who actually visit you.
Practical starting points, roughly in order of how often they pay off:
- Audit your third-party scripts. Chat widgets, analytics, heat-mapping and consent banners all attach listeners and run on the main thread. This is usually the single biggest lever, and the least popular one
- Check for non-passive scroll and touch listeners, including ones you did not write
- Break up long tasks. Anything holding the main thread for a long stretch delays every interaction that lands during it
- Reduce DOM size where a page has grown organically. Presentation delay scales with how much the browser has to recompute
- Be careful with client-side rendering. Building HTML in the browser moves work to exactly the device least able to do it
One thing we will not do is quote a figure for how many sites currently fail INP. Those numbers circulate widely and we could not trace them to a primary source, so they are not in this article.
Why this matters commercially
Responsiveness is the part of performance a visitor feels most directly. A page that loads quickly and then hesitates for half a second every time someone taps something reads as broken in a way that a slightly slower load does not. On mobile — which for most GCC audiences is the majority of traffic — that hesitation is where enquiries are lost.
If your site was built before 2024, it was very likely optimised against First Input Delay, which no longer exists. That is worth a look, not a panic.
We cover this as part of every build in our custom website service, and it is one of the more common reasons clients come to us about an existing WordPress site that has accumulated plugins over the years. For more on why mobile is the deciding case, see Mobile-First Design. If you want someone to look at your current numbers, get in touch.