How to Improve INP (Interaction to Next Paint) in 2026

To improve INP, aim for an Interaction to Next Paint of 200 milliseconds or less at the 75th percentile of real visits, measured separately on mobile and desktop. Find the slowest real click, tap or key press first, then shorten its input delay, its event-handler work and the rendering that follows.

What INP measures and what a good score is

INP is a stable Core Web Vital that replaced First Input Delay (FID). FID only timed the input delay of the first interaction; INP watches every click, tap and key press during the visit and reports roughly the slowest one. On pages with many interactions, one highest interaction is ignored for every 50.

• Good: 200 ms or less
• Needs improvement: over 200 ms, up to 500 ms
• Poor: over 500 ms

Scrolling, hovering and zooming are not counted. Google notes that Chrome usage data shows about 90% of a user's time on a page is spent after it loads, which is why INP covers the whole visit rather than only page load.

Step 1: Find slow interactions in field data

Start with real-user data, not a lab score. If your site is in the Chrome User Experience Report (CrUX), PageSpeed Insights shows INP at origin level and sometimes per URL. CrUX tells you there is a problem but not which interaction caused it, so add real-user monitoring (RUM). The free web-vitals library does this in a few lines:

• Install web-vitals and call onINP() with a function that sends the value to your analytics.
• Use the attribution build to record which element and interaction type (click, tap or keypress) was slowest.
• Report on visibilitychange, because mobile browsers often skip unload events. The library already handles this.

Step 2: Reproduce the slow interaction in the lab

Lighthouse page-load runs often show no INP because nobody interacts with the page. Instead, open Chrome DevTools, throttle the CPU, record a Performance trace and repeat the slow interaction. Also try clicking while the page is still loading, when the main thread is busiest. Total Blocking Time (TBT) is a reasonable lab proxy, but it does not replace INP.

Step 3: Reduce input delay

Input delay is the time between the user acting and your event handlers starting. It usually comes from long tasks that are already running, often script parsing, compiling and executing during startup, plus timers and overlapping interactions.

• Ship less JavaScript on first load. Defer or code-split anything that is not needed for the first screen.
• Audit third-party tags (chat widgets, A/B testing, analytics), which often run long tasks during startup.
• Remember that iframes count. A slow click inside an embedded widget still adds to your page's INP.

Step 4: Make event handlers do less, and yield

Processing duration is how long your callbacks take to run. Do the minimum needed for the visual update, then hand the rest back to the browser:

• Update the UI first, then defer non-urgent work (saving, analytics, recalculating counts) with requestAnimationFrame plus setTimeout(..., 0), as shown in web.dev's guide.
• Split long loops into chunks and yield between them so no single task blocks the main thread.
• Avoid layout thrashing, where you write styles and then read layout values (such as offsetHeight) in the same task. That forces a synchronous layout.

Step 5: Cut presentation delay

Presentation delay is the time from your handlers finishing to the next frame being painted. Large DOMs make rendering more expensive.

• Keep the initial DOM small. Render long lists, menus and tabs only when they are needed.
• Use CSS content-visibility: auto on below-the-fold sections so the browser skips rendering them until they are close to the viewport.
• Avoid injecting large chunks of HTML with client-side JavaScript in response to a click. Server-streamed HTML lets the browser yield on its own while it parses.

Step 6: Re-measure and repeat

Field data from CrUX covers a rolling 28-day window, so expect a few weeks before PageSpeed Insights reflects a fix. Your RUM data will show changes sooner. Google calls INP work iterative: once you fix the worst interaction, the next-slowest one becomes your INP, so keep working through the list. For a broader pre-launch pass, see our Next.js 16 App Router production checklist (Open shoppercove.com). To get help reading traces, see our guide to Chrome DevTools AI assistance (Open shoppercove.com).

FAQ

What is a good INP score?

200 milliseconds or less at the 75th percentile of page visits is good. Over 200 ms up to 500 ms needs improvement, and anything over 500 ms is poor.

Why does PageSpeed Insights show no INP for my page?

There may not be enough Chrome user data in CrUX, or visitors only scrolled or hovered, which INP does not count. Lab-only runs that never interact with the page also report no INP.

Did INP replace FID?

Yes. INP is FID's successor as the responsiveness Core Web Vital. It measures every interaction's full latency (input delay, processing and presentation), not just the first input's delay.

Sources

• 01web.dev/articles/inp
• 02web.dev/articles/optimize-inp
• 03github.com/GoogleChrome/web-vitals
• 04developer.chrome.com/docs/crux/methodology
• 05web.dev/articles/content-visibility