INP Explained: Why Your Site Feels Slow Even When It Scores Fast

There is a specific kind of frustration that speed scores do not capture. The page loads quickly, the images appear, everything looks ready, and then you tap a button and nothing happens for half a second. You tap again. Now it fires twice. That gap between looking ready and being ready is what Interaction to Next Paint measures, and it is the reason your analytics can show a fast site while your customers experience a slow one.

Why this matters now

INP replaced First Input Delay as Google's responsiveness metric in March 2024, and the change was far more demanding than the swap of one acronym for another suggests. FID measured the delay before the browser began processing your very first interaction. That is a low bar, and almost everyone cleared it. INP measures the full duration from interaction to visible response, across every interaction in the visit.

The arithmetic is what makes it strict. If a visitor interacts with your page 100 times, INP reports approximately the 95th slowest of those interactions, not the average. One catastrophically slow menu open on the fortieth tap will define your score. You cannot optimise the first interaction and declare the job done, which is exactly what FID allowed.

In 2026 Google refined the measurement methodology so it better captures sustained interaction latency on input-heavy pages, expanded soft-navigation support in the Chrome User Experience Report, and surfaced Time to First Byte alongside the existing metrics. Importantly the thresholds did not move. A good INP is still 200 milliseconds or less, LCP is still 2.5 seconds, CLS is still 0.1. What changed is how accurately the measurement reflects what users endure.

The scale of the problem is the striking part. As of the May 2026 CrUX release published on 9 June, only 55.9% of tracked origins pass all three Core Web Vitals. Almost half the measured web fails, and INP is the usual reason. If your site is in that group you are not an outlier, but you are leaving a straightforward advantage on the table.

This matters commercially because responsiveness is felt rather than measured by the people who pay you. Nobody has ever abandoned a form because of a metric. They abandon because they tapped Submit, nothing happened, and they were not sure whether it had worked.

Common mistakes to avoid

The mistakes here come from applying loading-speed thinking to a responsiveness problem. They are different problems and the fixes barely overlap.

• Testing on your own laptop. Your development machine is several times more powerful than the phone your customer is holding. INP is dominated by processing time, and processing time is dominated by device capability. A test on a MacBook tells you almost nothing about a mid-range Android.
• Trusting your Lighthouse score. Lighthouse runs a simulated load in a lab. INP requires a real person interacting with a real page over a real session, so it comes from field data. A perfect Lighthouse score is entirely compatible with a failing INP.
• Compressing more images. Image weight affects LCP, not INP. Teams often respond to a responsiveness complaint with another round of image optimisation, spend two weeks on it, and move the wrong number.
• Adding tags without ever removing any. Every analytics script, chat widget, heatmap tool and remarketing pixel competes for the same single main thread. Most sites accumulate these for years and audit them never.
• Blaming the hosting. Server speed governs how fast the page arrives. INP governs what happens once it is here, and that work happens in the browser. Better hosting will not fix it, though slow hosting causes other problems worth reading about in how slow hosting quietly destroys your SEO.

The deeper misunderstanding is about where the time goes. When someone taps a button, the browser has to run your JavaScript event handler, recalculate layout, repaint the screen, and only then show a change. If the main thread is busy running a third-party script when that tap arrives, the tap simply waits. It is not that your code is slow. It is that your code is queued behind somebody else's.

This is why third-party tags are the first place to look. A chat widget that loads a 400 kilobyte bundle and initialises on page load will block interactions for hundreds of milliseconds on a mid-range device, and it will do it on every single page view, for a feature perhaps two percent of your visitors use.

Step-by-step plan to fix INP

Work through this in order. The early steps are free and frequently solve the problem outright, which means you may never need the expensive ones.

1. Get your real INP from field data. Open Search Console and find the Core Web Vitals report, or use the CrUX data in PageSpeed Insights. Look at mobile and desktop separately. Desktop usually passes comfortably while mobile fails, and reporting a blended figure hides the entire problem.
2. Identify which page templates fail. You do not have hundreds of INP problems, you have three or four templates repeated across hundreds of URLs. Group the failures by template and you have reduced the work by an order of magnitude.
3. Inventory every third-party script. List them all with the business owner of each and the last date anyone confirmed it was needed. In most audits, between a quarter and a half of the tags on a site are for tools nobody uses any more. Delete those first. It is the cheapest performance work available.
4. Defer everything that is not needed for the first interaction. Chat widgets, heatmaps, review carousels and social embeds do not need to initialise while the page is loading. Load them on user interaction or after the page is idle. This alone frequently moves INP from failing to passing.
5. Break up long tasks. Any single JavaScript task running longer than 50 milliseconds blocks every interaction that arrives during it. Ask your developer to find long tasks in the Performance panel and split them so the browser gets regular chances to respond.
6. Give immediate visual feedback on every interaction. When someone taps Submit, disable the button and change its label instantly, before the work completes. This does not make the operation faster but it does stop the double-tap, and INP measures time to next paint. A fast visible acknowledgement is a genuine improvement, not a trick.
7. Reduce what happens on page load. Animations that run on scroll, carousels that autoplay, and libraries that initialise on every page all consume main thread time that your visitors' taps need. Question each one against its actual commercial contribution.
8. Re-measure with field data after three weeks. CrUX reports on a 28-day rolling window, so your improvement will not appear immediately. Changing more things while you wait makes it impossible to attribute the movement.
9. Fix the next template. Once one template passes, apply the same changes to the next. The fixes are almost always identical because the causes are shared.
10. Set a tag policy. Every new third-party script needs a named owner and a review date. This is what stops the problem returning in eighteen months, which otherwise it reliably will.

Steps three and four are where most of the gain lives. It is not glamorous work and it does not require a rebuild. It requires someone to open the tag manager, ask what each script is for, and delete the ones with no answer.

If loading speed is also a problem, and it usually is, treat it as a separate workstream with separate fixes. Our piece on page speed as a revenue engine covers that side, and the commercial argument for both is the same.

INP checklist

Before you accept a template as fixed, confirm all of the following.

• Field INP for mobile is 200 milliseconds or less at the 75th percentile.
• Mobile and desktop have been checked separately, not blended.
• Every third-party script has a named owner and a confirmed purpose.
• Nothing non-essential initialises during page load.
• Every button and link gives visible feedback within 100 milliseconds of being pressed.
• No single JavaScript task exceeds 50 milliseconds on a 4x throttled CPU.
• The page has been used, not just loaded, on a real mid-range phone.
• Form submission disables the button and changes its state immediately.
• Scroll and hover animations have been justified against their cost.
• A tag review date is in the calendar.

How to measure impact

INP is a field metric, which means patience is part of the method. Lab tools give you an instant answer to a slightly different question, and confusing the two is the most common reporting error.

Use Search Console as your source of truth. It reports the 75th percentile of real visits over a 28-day rolling window. That lag is not a flaw. It is what makes the number trustworthy, because it reflects actual devices on actual networks rather than a simulation.

Use DevTools for diagnosis, never for reporting. The Performance panel with 4x CPU throttling tells you which interaction is slow and why. It will not tell you your score. Keep the two jobs separate and you avoid most of the confusion in this area.

Watch the URL group counts, not just the headline. Search Console groups URLs into good, needs improvement and poor. Migration between those buckets is the clearest evidence your template fix worked, and it shows up before the aggregate number moves much.

Connect it to behaviour. Look at form completion rate and mobile bounce rate on the templates you fixed. Responsiveness improvements tend to show up in completion before they show up anywhere else, because the double-tap and the abandoned form are the same event seen from two angles.

Set the review at four weeks, not one. Anything sooner is reading noise.

Key terms in plain English

INP: Interaction to Next Paint. The time from a user interacting to the screen visibly updating, assessed across the whole visit. Good is 200 milliseconds or less.

Core Web Vitals: Google's three user experience metrics. LCP for loading, INP for responsiveness, CLS for visual stability.

Field data: Measurements from real visitors on real devices. Slower to arrive and far more trustworthy than lab data.

Lab data: Measurements from a simulated load in a controlled environment. Instant, repeatable, and not what Google scores you on.

Main thread: The single queue where the browser does almost all its work. If it is busy, your visitor's tap waits.

Long task: Any single piece of JavaScript running over 50 milliseconds, during which the page cannot respond to anything.

75th percentile: The threshold where three quarters of visits are faster. Google scores you here, so your typical visitor is not the one being measured.

CrUX: The Chrome User Experience Report. Google's public dataset of real-world performance, updated monthly on a 28-day window.

Conclusion and next move

INP is the metric that finally measures the thing users complain about. Not how long the page took to appear, but whether it responds when they touch it. Almost half the web fails it, which means passing is still a differentiator rather than table stakes.

The fix is rarely a rebuild. In most cases it is an honest audit of the third-party scripts that accumulated over the last few years, plus deferring the things that do not need to run immediately. Start by opening your site on a cheap Android phone and using it properly. Whatever annoys you in the first minute is your highest-value fix, and you did not need a tool to find it.