INP Too High: How to Diagnose and Fix It

What this check flags

This audit fires when your Interaction to Next Paint exceeds the 200ms good threshold. Google grades INP at the 75th percentile of real user visits: 200ms or less is good, anything over 500ms is poor, and the range in between needs improvement. The metric matters because it became an official Core Web Vital in March 2024, replacing First Input Delay. FID only measured the input delay of the first interaction, while INP watches every click, tap, and key press across the entire page visit. That makes it far harder to game and far more honest about how your site actually feels. If you want the full background, read our INP deep dive.

What INP measures

INP reports the worst interaction observed on a page (with a small allowance for outliers on pages with many interactions). Each interaction is timed across three phases that add up to the final number:

Input delay is the wait before your event handler can even start, usually because the main thread is busy with other work. Processing duration is the time your event handlers spend running. Presentation delay is the time the browser needs to render and paint the next frame after your handlers finish. A slow score can come from any of the three, and the fix differs depending on which phase dominates.

The three phases, and the fix for each

This is the table to keep open while you profile. Find the phase eating your budget, then apply its fix, chasing the wrong phase wastes days:

The usual suspects

Long JavaScript tasks

Any task that holds the main thread for more than 50ms is a long task. While one runs, the browser cannot respond to input, so a tap that arrives mid-task inherits the remaining task time as pure input delay.

Heavy event handlers

Click handlers that filter large arrays, recalculate state, fire analytics, and update the DOM all in one synchronous block push processing duration through the roof.

Third-party scripts

Tag managers, chat widgets, A/B testing tools, and ad scripts compete for the same main thread your interactions need. They are a frequent cause of high input delay on otherwise lean pages.

Layout thrash on click

Reading layout properties like offsetHeight right after writing styles forces the browser into repeated synchronous reflows inside your handler, inflating both processing and presentation time.

Quick wins

Break up long tasks so the browser gets regular chances to handle input. Yield to the main thread inside heavy loops, ideally with scheduler.yield() where supported, falling back to a setTimeout wrapper:

async function processChunks(items) {
  for (const chunk of items) {
    renderChunk(chunk);
    if ('scheduler' in window && 'yield' in scheduler) {
      await scheduler.yield();
    } else {
      await new Promise(r => setTimeout(r, 0));
    }
  }
}

Inside event handlers, do only what is needed to paint the visual response, then defer the rest. Debounce input handlers that fire rapidly, such as search-as-you-type. Audit your third parties ruthlessly: remove tags nobody owns anymore, lazy-load chat widgets until first interaction, and keep what remains out of the critical path. Finally, avoid forced reflows by batching DOM reads before DOM writes.

How to detect it

1. PageSpeed Insights. Start with field data. The CrUX assessment at the top tells you what real Chrome users experience at the 75th percentile. Remember: a lab run never clicks anything, so PSI's lab section shows no meaningful INP.
2. CrUX. Query the Chrome UX Report directly for page- or origin-level INP, segmented by phone and desktop, so you know which device cohort is dragging the score down.
3. Chrome DevTools. Open the Performance panel, record a trace while actually interacting with the page, and read the interaction track. Long tasks show as red-flagged blocks; the interaction breakdown shows which of the three phases dominates.
4. The web-vitals library. Google's web-vitals JS library exposes onINP() with attribution, and the Long Animation Frames API gives you script-level blame in the field, so you see exactly which function blocked a real user's tap.
5. Search Console. The Core Web Vitals report groups failing URLs by "INP issue," so you find every template with slow interactions rather than testing pages one at a time.

Lab and field numbers often disagree here, and knowing why is half the battle; our guide to field vs lab data walks through it.

How to fix it

Once the trace names the dominant phase, apply that row of the phase table: break up long tasks and yield for input delay, strip synchronous work out of handlers for processing duration, and batch DOM reads before writes for presentation delay. Target the single worst interaction first, since INP reports the worst case, then re-check the field data after the 28-day CrUX window catches up.

Common mistakes

The biggest one: testing only in the lab. A default Lighthouse run loads the page but never clicks anything, so it cannot produce a meaningful INP value. INP needs real interactions, which means field data or a manually recorded DevTools trace. Other classics include optimizing the homepage while the worst interactions live in checkout, testing on a fast desktop when your audience is on mid-range phones, and shipping a fix without waiting the roughly 28 days CrUX needs to reflect it.

FAQ

Is INP a ranking factor?

INP is part of Core Web Vitals, which feed into Google's page experience signals. Treat it as a tiebreaker, not a silver bullet, and fix it primarily because slow interactions cost conversions.

Why does PageSpeed Insights show no INP for my page?

CrUX only reports INP when a URL or origin has enough real Chrome user traffic with interactions. Low-traffic pages fall back to origin-level data or show nothing, in which case you diagnose with DevTools traces instead.

My INP is 250ms. How urgent is this?

That sits in the needs improvement band, not poor territory. It is worth fixing, but prioritize it behind anything over 500ms, and target the single worst interaction first since INP reports the worst case.

Which of the three phases is usually the problem?

Most often processing duration, from handlers doing too much synchronously, closely followed by input delay from long tasks and third-party scripts. Presentation delay dominates less often, usually on pages with very large DOM updates. Profile before you assume.