Because loading fast and responding fast are two different things. A page can paint in under a second and still freeze for half a second when someone taps a button. Interaction to Next Paint is the Core Web Vital that measures that second problem, and a high Lighthouse score does not guarantee you pass it.
This is one of the most common gaps we see. A site scores in the high nineties, the client is happy, then someone opens the mobile menu and it stutters. Nothing in the lab report explained it.
The reason is simple. Lab tools load your page and grade the load. They do not sit there clicking things the way a real visitor does. INP is built from what real people actually do on your site, so it catches the problems a load test never sees.
INP is a Core Web Vital that measures how quickly your page responds to a user. Google describes it as assessing a page''s overall responsiveness by observing the latency of all click, tap, and keyboard interactions. It reports one number that represents your page''s worst realistic response time.
The key word in that definition is "all". INP watches every interaction on the page, not just the first one. If your hero button is instant but your pricing filter takes 600 milliseconds, INP reports the filter.
Google''s documentation on web.dev breaks each interaction into three phases. Input delay is the time before your event handlers start running. Processing duration is the time your handler callbacks take to execute. Presentation delay is the time from when your callbacks finish to when the browser paints the next frame.
That three-phase split is the most useful thing in the whole metric. It tells you where to look. A long input delay means something else was already blocking the main thread. A long processing duration means your own code is slow. A long presentation delay means the browser struggled to render the result.
INP became a Core Web Vital on 12 March 2024, replacing First Input Delay. Google removed FID from Search Console that same day and gave other tools, including PageSpeed Insights and the Chrome UX Report, a six-month deprecation window. FID is now retired and its documentation carries a deprecation notice.
The path there was slow and public. Google introduced INP as an experimental metric in May 2022, moved it to pending status in May 2023, then promoted it to a stable Core Web Vital in March 2024. Nobody was ambushed by this change.
The reason for the swap is worth understanding. FID only measured the delay before the first interaction was handled. It never measured how long the work itself took, and it ignored every interaction after the first. That made FID very easy to pass and almost useless as a signal. Google said directly that a new metric was needed to capture aspects of interactivity that FID did not.
If your team still talks about First Input Delay in performance reviews, that habit is now two years out of date. We updated our own reporting when the change landed, and we cover how these metrics feed search performance in our guide to Core Web Vitals and SEO.
A good INP is 200 milliseconds or less. Between 201 and 500 milliseconds needs improvement. Anything above 500 milliseconds is poor. Google measures this at the 75th percentile of page loads, which means three quarters of your real visits must hit the threshold before you pass.
That 75th percentile rule is the part people miss. Your average interaction can be excellent while you still fail. If one in four visits is slow, you fail. The metric is deliberately built around the unlucky quarter of your audience, usually people on cheaper phones and worse networks.
The bar is also tighter than it sounds. Two hundred milliseconds is roughly the point where a response stops feeling instant to a person. Google did not pick a number that flatters websites. It picked the number where users start noticing.
Most do, and INP is the Core Web Vital that improved fastest. The HTTP Archive Web Almanac reported in 2025 that 80% of mobile home pages had a good INP score, up 7 percentage points from 2024. Passing all three Core Web Vitals is much harder, and far fewer sites manage it.
The same 2025 Web Almanac found that 48% of websites passed all Core Web Vitals on mobile, up from 44% in 2024 and 36% in 2023. On desktop the figure was 56%, up from 55%. So the web is improving, but slowly, and mobile is still where most sites fail.
Breaking it down by metric shows where the trouble sits. The 2025 Web Almanac reported 62% of mobile pages with good Largest Contentful Paint and 81% with good Cumulative Layout Shift. INP at 80% on mobile home pages is in decent company. Largest Contentful Paint is the metric dragging most sites down.
We read that as good news with a catch. If four out of five sites pass INP, passing is not a differentiator. Failing, though, is a real liability, because you are now in the slow minority on the metric users feel most directly.
JavaScript running on the main thread. The browser has one thread for both your scripts and your rendering, so any long task blocks the response to a tap. Third-party tags, heavy event handlers, oversized DOM trees, and layout thrashing are the usual sources, roughly in that order.
Third-party scripts are the most common cause we find. Analytics, chat widgets, heat maps, consent banners, and ad tags all run code you did not write and cannot profile easily. Each one adds tasks to the same thread that has to answer your visitor''s click. We wrote about that specific cost in our piece on how third-party scripts slow down your website.
Layout thrashing is the sneakiest cause. Google''s optimization guide explains that reading a style value right after you change it in JavaScript forces the browser to do synchronous layout work it could otherwise have done later. One line of code in a scroll or click handler can create a stall that shows up in every interaction.
DOM size matters too. Google''s guidance notes that large DOM trees correlate with higher rendering costs, and suggests flattening your DOM or adding elements during interactions instead of shipping them all up front. This one bites Webflow sites and template-heavy builds in particular, because it is easy to nest wrappers until a simple section carries dozens of elements.
Break long tasks into short ones, yield to the browser so it can paint, and stop doing work you do not need. Google''s own optimization guidance centres on breaking up long tasks with setTimeout, yielding before rendering, avoiding layout thrashing, and reducing DOM size. There is no single switch.
Breaking up long tasks is the first move. If a click handler runs 400 milliseconds of work in one go, the browser cannot paint until it finishes. Splitting that work into several short tasks with setTimeout lets the browser respond in between. The total work is the same. The perceived responsiveness is completely different.
Yielding for rendering is the second move. Google''s guide shows combining requestAnimationFrame with setTimeout so background work does not block the next frame from being presented. This is how you keep presentation delay low when a click triggers a visual change.
The CSS property content-visibility is the cheapest win on long pages. Google describes it as a way to lazily render elements as they approach the viewport, which cuts rendering work during both load and interaction. On a long marketing page with many sections below the fold, that can be a few lines of CSS for a real gain.
The last move is the one nobody likes. Remove scripts. Every tag you delete is a task that can never block a click again. We have never regretted removing a tracking script that nobody was reading reports from.
You need field data, not lab data. INP comes from real user interactions, so tools that just load your page cannot produce it. The Chrome UX Report collects it from real Chrome users, and it surfaces in PageSpeed Insights and Google Search Console. Chrome DevTools helps you reproduce a specific slow interaction.
Start with PageSpeed Insights and read the field data section at the top, not the Lighthouse score below it. That top section is real user data. The score below is a simulated load. Confusing the two is the single most common mistake we see in performance conversations.
Then reproduce the problem locally. Open Chrome DevTools, throttle the CPU, and interact with the thing your users complain about. The performance panel will show you the long task and the function inside it. That is where the fix lives.
One caveat on the Chrome UX Report. It only includes origins with enough real traffic, so a new or low-traffic site may show no field data at all. That does not mean you pass. It means nobody is watching yet, and you should still profile by hand. This is also why we check field data on sites we have already tuned, even when our builds average a 98 PageSpeed score in the lab.
Yes, but modestly. Google states plainly that Core Web Vitals are used by its ranking systems, and INP is one of the three. Google also says there is more to great page experience than Core Web Vitals scores alone. Treat INP as a tiebreaker, not a trump card.
The more practical argument is about behaviour, not rankings. A page that stutters when someone taps a button loses that person. Slow interactions kill form completions, filter usage, and checkout flows. Those losses show up in revenue long before they show up in a ranking report.
There is also a render side to this that people conflate with INP. If your content only exists after JavaScript runs, crawlers can miss it entirely, which is a different failure with a different fix. We separated those two problems in our article on render-blocking resources.
Open PageSpeed Insights, read your field INP, and find the interaction people actually use most. Fix that one. Then audit your third-party scripts and delete the ones nobody reads. Those two moves solve most INP problems without a rebuild, and they take days rather than weeks.
If your INP is already under 200 milliseconds, do not spend more time here. Check your Largest Contentful Paint instead, because the 2025 Web Almanac data suggests that is where most sites are losing. Optimising a metric you already pass is the most expensive kind of busywork.
If you are staring at a slow site and not sure which of these is your real problem, let''s talk. We are happy to look at your field data with you and tell you honestly whether it needs a tune-up or a rebuild. You can reach us at phoenix.studio.
Tell us where you want to go. We'll tell you how we'd get you there.