Interaction to Next Paint (INP): Definition, Thresholds, Fixes

What is Interaction to Next Paint (INP)?

Interaction to Next Paint (INP) is a Core Web Vital that measures how quickly a page responds to user input. It looks at every click, tap and key press during a visit, times each one from the input until the browser paints the next frame, and reports the slowest. A page is rated good when INP is 200 milliseconds or less at the 75th percentile of real page loads.

INP replaced First Input Delay (FID) as a Core Web Vital on 12 March 2024. FID only looked at the delay before the first interaction was handled. INP covers all interactions and the full time to the next paint, so it describes how the page feels to use, not only how it feels at load.

INP thresholds

The thresholds are applied to field data, split by mobile and desktop. A page passes when at least 75% of page loads are at or under the limit.

How INP works

Every interaction is split into three phases, and a delay in any of them raises INP:

• Input delay: the time before event handlers can start, usually because the main thread is busy with other work.
• Processing time: how long your event handlers take to run.
• Presentation delay: the time from the end of the handlers until the browser shows the next frame.

Only clicks, taps and key presses count. Hovering, zooming and scrolling are not interactions for INP. The page reports its slowest interaction, except that on pages with many interactions one outlier is ignored for every 50 interactions. Most pages never reach 50, so in practice INP is the worst interaction of the visit. The 75th percentile across all page views is then reported, like the other Core Web Vitals.

Example

A shop page loads fast, but the "Add to cart" button runs a large synchronous script that recalculates prices, updates the cart and re-renders the whole product list. A user taps the button and nothing visibly changes for 600 ms. LCP and CLS are fine, but INP for that page is about 600 ms and rated poor. Splitting the work so the button shows its new state first, and the rest runs afterwards, brings the interaction back under 200 ms.

How to measure INP

INP needs real interactions, so it is a field metric first. The Chrome UX Report (CrUX) publishes it for sites with enough Chrome traffic, and real user monitoring (RUM) with Google's open-source web-vitals library shows which interaction and which element are slow:

import { onINP } from 'web-vitals';
onINP((metric) => navigator.sendBeacon('/rum', JSON.stringify(metric)));

For a quick check of how a URL does for real users, use the free Core Web Vitals checker, which reads CrUX data and reports LCP, INP and CLS. In lab tests a click usually never happens, so Total Blocking Time (TBT) is the common stand-in. web.dev describes TBT as a reasonable lab proxy but not a substitute for measuring INP in the field.

How to improve INP

• Break up long tasks. Any task over 50 ms on the main thread can delay input. Yield between chunks of work so the browser can paint.
• Do less in the handler. Update what the user must see first, and defer analytics, logging and non-urgent state to later.
• Cut third-party script cost. Tag managers, chat widgets and ads run on the same main thread as your code.
• Move heavy computation off the main thread with a web worker.
• Watch hydration. A click that arrives while a framework is still hydrating waits for it.
• Keep the DOM small. Large re-renders after a click make the presentation delay long.

Common mistakes

• Reading only a Lighthouse score. A green lab run says little about interactions that never happened in the test.
• Testing only on a fast laptop. Mid-range phones are usually much slower than a developer laptop on the same JavaScript.
• Fixing page load only. INP is mostly decided after load, by what happens on click.
• Expecting a fix to show at once. CrUX is a rolling 28-day field dataset, so improvements appear gradually.

INP and performance monitoring

INP is measured on real users, so a one-off test is not enough. Track it over time next to LCP and CLS, and catch regressions after a release. LoadFocus page speed monitoring runs scheduled Lighthouse audits, including TBT, from cloud regions, which helps you spot the main-thread regressions that usually precede a worse INP. For a step-by-step optimization guide, read how to optimize Interaction to Next Paint, and for setting up alerts see how to monitor Core Web Vitals with alerts and reports. The reference definition is on web.dev.

FAQ: Interaction to Next Paint

What is a good INP score?

200 milliseconds or less at the 75th percentile of page loads. Between 200 and 500 ms needs improvement, and over 500 ms is poor.

Did INP replace FID?

Yes. INP became a Core Web Vital in place of First Input Delay on 12 March 2024. FID only measured the input delay of the first interaction.

Why is my Lighthouse score fine but my field INP poor?

Lab runs rarely include real clicks or key presses, so they miss slow interactions. Total Blocking Time is a lab indicator, but only field data from real users shows your actual INP.

Which interactions count for INP?

Clicks, taps and key presses. Hovering and scrolling are not counted, although a scroll that includes a tap or key press can contain one that is.

How do I find the slow interaction?

Collect INP with the web-vitals library in your own RUM, which can report the element and the phase that was slow, or record a trace in Chrome DevTools and look at the interaction in the Performance panel.

Does hydration affect INP?

Yes. Hydration is JavaScript running on the main thread, so an interaction during hydration is delayed. Smaller bundles, partial hydration and server components reduce the effect.