What is Interaction to Next Paint (INP)?

Interaction to Next Paint (INP) is a Core Web Vitals metric that measures how responsive a web page is. INP records the delay between a user interaction, such as a click, a tap or a keystroke, and the next visible response on screen, across the entire visit. INP has been a stable Core Web Vital since March 2024, replacing the earlier First Input Delay (FID) metric. A good score is a delay of no more than 200 milliseconds at the 75th percentile of all page views.

INP answers a simple question from the visitor’s point of view: how quickly does the page react when I click or type something? A page can load in a flash and still feel sluggish if every click needs a noticeable pause. That perceived sluggishness is exactly what INP makes measurable, which is why it belongs in every technical Core Web Vitals optimization.

INP at a glance

What exactly is INP?

INP measures the full latency of an interaction, not just the moment the browser accepts the input. Every interaction runs through three phases, and INP adds them up to the complete delay until the next rendered frame (the “next paint”):

• Input delay: the time from the click until processing starts. If the main thread is busy with a long task, the input has to wait.
• Processing time: how long the matching event handler in your JavaScript needs to work out the response.
• Presentation delay: the time until the browser actually paints the result on screen.

Across the whole visit the browser collects every interaction and reports one representative value at the end, which on most pages is the slowest interaction. Clicks, taps and keystrokes count towards it; plain scrolling and hovering do not, because they do not have to trigger an immediate rendered response.

What is a good INP score?

A good INP score is no more than 200 milliseconds. Google rates INP, like all Core Web Vitals, at the 75th percentile: at least 75 percent of all page views have to stay within the threshold for the page to count as “good”. There are three rating bands:

• Good: 200 ms or faster. The page feels fluid and interactions seem immediate.
• Needs improvement: between 200 ms and 500 ms. Visitors notice a slight delay.
• Poor: over 500 ms. The page reacts noticeably slowly, which makes people leave sooner.

One point matters here: the 75th percentile approach means that a few slow interactions can tip the whole rating. It is not enough for the page to react quickly most of the time, the rarer and heavier interactions have to stay within the limit too. How fast the page loads is measured by Largest Contentful Paint (LCP) instead, and how stable the layout stays by Cumulative Layout Shift (CLS).

INP vs. FID: what changed?

INP replaced First Input Delay (FID) as a Core Web Vital because it reflects the responsiveness of a page far more completely. The difference comes down to three points:

• All interactions instead of only the first one: FID measured only the delay of the first interaction on a page. INP takes every interaction during the whole visit into account.
• Full latency instead of input delay only: FID captured just the input delay up to the start of processing. INP measures the complete chain up to the visible result, including processing and presentation.
• A more realistic picture: because FID looked at the first click only, and only at its beginning, many pages scored well on FID even though they felt sluggish later on. INP closes that gap.

INP officially became a stable Core Web Vital on March 12, 2024, and FID was removed from the Core Web Vitals in September 2024. In practice that means anyone who once optimized a page for a good FID score should check INP separately, because a good old FID value guarantees nothing about INP.

How is INP measured?

INP is measured primarily with field data from real users, but it can also be approximated in the lab. The two perspectives complement each other:

• Field data (authoritative): the Chrome User Experience Report (CrUX) collects anonymized INP values from real Chrome users. That data feeds into Google Search Console and PageSpeed Insights. Only field data counts towards the official Core Web Vitals assessment.
• Lab data (for diagnosis): tools such as Lighthouse or the Chrome DevTools simulate interactions to pinpoint specific bottlenecks. Since nobody really clicks in the lab, the lab value is only an approximation.

A dependable assessment needs enough real traffic for CrUX data to exist. Without it, only lab diagnosis helps, or your own real user monitoring that records the INP values of your visitors directly in the browser.

How do you improve INP?

You improve INP mainly by taking load off the browser’s main thread, because blocking JavaScript is the most common cause of poor scores. The most effective levers:

1. Break up long tasks: split large JavaScript tasks into smaller chunks and yield the main thread in between, so that pending interactions do not have to wait.
2. Slim down event handlers: keep the work inside click and input handlers short. Expensive work that is not immediately visible can be deferred.
3. Reduce rendering work: a large or deeply nested DOM stretches the presentation phase. Lean markup shortens the path to the next paint.
4. Review third-party scripts: tracking, chat and advertising scripts often occupy the main thread unnoticed. Fewer third-party scripts, or ones loaded later, free up noticeable interactivity.

In practice, INP work is closely tied to the rest of the performance profile. A structured SEO audit shows which scripts and templates slow responsiveness down, and in which order the optimization pays off most.

Frequently asked questions about INP

Is INP a ranking factor?
As a Core Web Vital, INP is part of the page experience signal and therefore a ranking factor, although a comparatively weak one. Relevance and content quality weigh much more heavily. A good INP never hurts, but it does not replace a good page.

Why is my INP good in the lab but poor in the field?
Because nobody really clicks in the lab. Lab tools simulate single interactions, while real visitors work through complex forms, menus and filters. Only the field data from CrUX counts towards the assessment.

Does INP apply to mobile devices as well?
Yes, and it is especially critical there. Mobile processors are weaker, so blocking JavaScript hits harder. Google evaluates mobile and desktop values separately.