INP Explained: The Core Web Vital Most Sites Now Fail (and How to Fix It)

Your site loads quickly. The Lighthouse score looks respectable. And yet Search Console says your pages fail Core Web Vitals, and the culprit is a metric called INP. This is the most common performance conversation I have with clients at the moment, because INP catches a problem older metrics missed: a page that looks ready but does not respond when you use it. Here is what it measures, why sites fail it, and how I track down and fix the slow interaction.

What INP measures

Interaction to Next Paint measures the delay between a visitor interacting with the page — a click, a tap, a key press — and the browser showing the next visual update in response. It replaced First Input Delay as a Core Web Vital in March 2024.

The difference is significant. First Input Delay only measured the first interaction, and only the waiting before your code started to run. INP looks at interactions across the whole visit, reports one of the slowest, and includes the full cycle:

• Input delay: the time before your event handler can even start, usually because the browser is busy with something else.
• Processing time: how long your event handlers take to run.
• Presentation delay: the time for the browser to recalculate layout and paint the result.

Scrolling and hovering do not count. Clicks, taps and key presses do.

The thresholds

Google assesses INP at the 75th percentile of real visits, separately for mobile and desktop.

INP	Rating
200 ms or less	Good
Over 200 ms, up to 500 ms	Needs improvement
Over 500 ms	Poor

200 milliseconds sounds generous until you test on a mid-range Android phone with a few marketing scripts running. For the other two vitals and what they mean commercially, see my Core Web Vitals guide for business owners.

Why so many sites fail it

The browser's main thread does almost everything: it runs JavaScript, calculates layout, paints the screen and responds to input. It can only do one thing at a time, so anything that holds it for a long stretch makes the next interaction wait. Tasks over 50 milliseconds are called long tasks, and they are the usual suspects.

• Third-party scripts. Chat widgets, analytics, tag managers, heatmaps, review badges and ad pixels all compete for the main thread. On the sites I audit, these are the most common cause.
• Heavy hydration. Framework-built sites often render HTML on the server, then run all the component code again in the browser to make it interactive. Until that finishes, taps queue up.
• Expensive event handlers. A filter click that re-renders an entire product grid, or a form that validates every field on every keystroke.
• A huge DOM. Pages with many thousands of elements make every layout and paint more expensive, so even a small change takes a long time to appear.

I cover the wider set of culprits in ten common web performance mistakes, and if you run WordPress, why your WordPress site is slow covers the plugin side.

Step one: find the slow interaction in field data

Start with real users, not lab tests. A standard Lighthouse run loads the page but does not click around it the way a customer does, so it cannot report INP; Total Blocking Time is its closest stand-in.

1. Search Console's Core Web Vitals report shows which groups of URLs fail INP on mobile and desktop.
2. PageSpeed Insights shows field INP for a specific URL or the whole origin, when Google has enough Chrome user data.
3. Real-user monitoring tells you which element was involved. Google's open-source web-vitals library has an attribution build that reports the target element and the split between input delay, processing and presentation. Sending that to your analytics is the fastest way to stop guessing.

You are looking for a pattern: the mobile menu button, the add-to-cart button, the filter sidebar, the cookie banner.

Step two: reproduce it in Chrome DevTools

1. Open DevTools and go to the Performance panel. Its live metrics view shows INP for your own interactions as you use the page, a quick way to confirm the problem.
2. Turn on CPU throttling so your laptop behaves more like a mid-range phone.
3. Start a recording, perform the slow interaction, and stop.
4. Find the interaction in the Interactions track and look at what ran on the main thread during it. Long tasks are flagged, and the flame chart shows which scripts and functions took the time.

Usually the answer is obvious once you see it: a third-party script, a framework re-render, or a layout recalculation touching thousands of elements.

Fix one: yield to the main thread

If a handler has a lot to do, do the visible part first and hand control back to the browser before doing the rest. That lets it paint the response — the menu opening, the button changing state — while the remaining work runs afterwards.

function yieldToMain() {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

button.addEventListener("click", async () => {
  showLoadingState();    // visible feedback first
  await yieldToMain();   // let the browser paint
  await updateResults(); // heavier work afterwards
});

scheduler.yield() is available in newer browsers; the setTimeout fallback works everywhere.

Fix two: break up long tasks

The same principle applies beyond event handlers. Any long block of JavaScript — processing a large list, initialising several widgets on load — can be split into smaller chunks with a yield between them. The total work is the same, but the browser gets a chance to respond to input between chunks. Also look for work that does not need to happen at all: analytics events that could be batched, calculations that could be done once on the server, validation that could wait until a field loses focus.

Fix three: put third-party scripts on a diet

• Remove scripts nobody uses. Most tag managers I open contain a pixel or two from campaigns that ended long ago.
• Load the rest after the page is interactive, or only when needed. A chat widget can load when someone clicks a placeholder button rather than on every page view.
• Check what each remaining script costs in the Performance panel, then decide whether it earns its place.

On Shopify, apps are the usual source; I cover how to tame them in speeding up a slow Shopify store.

Fix four: less hydration and a smaller DOM

Ship less JavaScript to hydrate

If your site uses React or a similar framework, the cheapest interaction is one that does not wait for hydration. Server Components render on the server and send no component code to the browser, so only the genuinely interactive parts need hydrating; I explain the approach in React Server Components explained. On any stack, lazy-load components that sit below the fold or behind a click, and do not ship a full framework for a page that only needs a menu toggle.

Shrink the DOM

Paginate or virtualise very long lists, remove duplicated markup such as separate mobile and desktop menus, and use CSS content-visibility: auto on long off-screen sections so the browser skips rendering them until they are needed.

Check you actually fixed it

Field data updates slowly because it covers a rolling 28-day window. Confirm the fix locally in DevTools, ship it, then watch your real-user monitoring and Search Console over the following weeks. A page that responds instantly is also better business, as I explain in the hidden ROI of a fast website.

Failing INP and not sure why? Send me the URL and I will find the slow interaction and tell you exactly what is causing it.