How Interaction to Next Paint Scores Your Worst Click

What is INP (Interaction to Next Paint)?

Chrome measures Interaction to Next Paint as the duration of a page's worst interaction, timed from the moment a visitor clicks, taps or presses a key to the moment the browser paints the frame that shows the result. The metric covers the whole round trip: the wait before an event handler starts, the handler's own runtime, and the rendering work that follows it. Instrument it with the web-vitals library or any field collector, then read it per route.

Chrome counts mouse clicks, touchscreen taps and key presses on physical or onscreen keyboards, and scrolling, hovering and zooming produce no INP sample at all, per the metric definition published by the Chrome team on web.dev (accessed September 2026). INP is the only one of the three Core Web Vitals that scores responsiveness after the page has loaded, and it reports nothing until real people click things, so the number Google acts on comes from real user monitoring at p75.

What are the three phases of an interaction?

Every interaction splits into input delay, processing duration and presentation delay, and INP is the sum of all three. Each phase has a different owner inside the browser, so a single INP number tells you nothing until you break it apart.

Phase	Starts when	Ends when	What is burning the time
Input delay	The visitor clicks, taps or presses a key	The first event callback starts running	Main thread already busy with script evaluation, timers, other handlers
Processing duration	The first event callback starts	The last callback finishes	Your own handler code, framework state updates, synchronous work
Presentation delay	The last callback finishes	The browser paints the next frame	Style recalculation, layout, paint, DOM size

The formula is a straight sum:

INP = input delay + processing duration + presentation delay

Work one example. A visitor taps a filter chip on a product listing and waits 620ms for the grid to change:

620ms = 180ms input delay + 90ms processing duration + 350ms presentation delay

The instinct is to optimise the handler, and the handler is the smallest slice at 90ms. Presentation delay owns 56 percent of the interaction, so the fix is in rendering: the filter re-renders 3,000 grid nodes and forces a full style recalculation. Cut the DOM the interaction touches and the 350ms collapses. Rewriting the handler saves 90ms at best and cannot reach 200ms on its own.

One tap, three delays

Input delay180ms

Processing duration90ms

Presentation delay350ms

What is a good INP score?

Chrome's thresholds put good at 200ms or less and poor above 500ms, measured at the 75th percentile of page views and split by mobile and desktop. The Chrome team publishes these cut-offs on web.dev, unchanged as of September 2026.

INP at p75	Verdict
200ms or less	Good
Above 200ms up to 500ms	Needs improvement
Above 500ms	Poor

Two hundred milliseconds is a tight budget once you divide it three ways, and the phase that blows its share first is the one to attack. Measure the split before you touch code: a search box fails on processing, an infinite-scroll grid fails on presentation.

Why did INP replace FID, and why did FID flatter sites?

Google made INP a Core Web Vital on March 12, 2024, replacing First Input Delay, and support for FID ended on September 9, 2024 (web.dev, Chrome team). FID measured one narrow thing: the input delay before the first event handler on the page could begin. It never timed the handler, and it never timed the paint that followed.

	First Input Delay	Interaction to Next Paint
Which interaction	The first one only	The worst one on the page
Which phases	Input delay only	Input delay, processing, presentation
Good at p75	100ms or less	200ms or less
Status	Retired September 9, 2024	Core Web Vital since March 12, 2024

FID flattered sites for two reasons. The first interaction on a page is a cheap one for most visitors: dismissing a cookie banner, focusing a search field, tapping accept on a consent dialog. The expensive interactions come later, once the visitor has committed to the page, and FID never looked at them.

FID also stopped its clock before your code ran, so a filter handler that blocked the main thread for 900ms scored a perfect FID as long as the browser could enter the handler quickly. web.dev is explicit that counting processing time in FID could have pushed developers to wrap handler logic in an asynchronous callback, moving it out of the measured task without helping the person waiting. INP closes both holes.

Which interaction does INP report when a page has hundreds?

Chrome reports the page's worst interaction, with an allowance for outliers on busy pages. For pages with 50 or fewer interactions, the highest one becomes the page's INP. Above 50, Chrome sets aside one high interaction for every 50 recorded, so a session with 130 interactions discards two of the highest and reports the next one down.

Two aggregations stack here, and confusing them is a common triage mistake: the worst-interaction rule picks one number per page view, then the 75th percentile across page views picks one number per URL. Read that distribution the way you read Largest Contentful Paint, with p75 next to p90 and the sample count.

What causes a slow INP, and what fixes each cause?

Slow INP has three families of cause, one per phase, and each takes a different fix.

Input delay comes from a main thread that is already busy when the click lands: script evaluation during page load, timers and fetch handlers competing for the same thread. Cut the amount of JavaScript that runs at all, and break up any long task over 50ms so the browser gets a gap to accept input.

Processing duration comes from handlers that do too much in one go. Yield to the main thread with scheduler.yield() or setTimeout() so the browser can paint an intermediate frame, and defer anything the visitor does not need immediately behind requestAnimationFrame() plus a yield. Paint feedback first, then do the work.

Presentation delay comes from rendering. Large DOMs cost more to render than small ones, so flatten the tree and add elements during the interaction instead of shipping them upfront. Narrow the scope of style recalculation and use content-visibility to skip offscreen work. Hunt layout thrashing first: writing a style and reading it back in the same task forces a synchronous layout, and batching all reads before all writes removes it. The same rendering work moves Cumulative Layout Shift, so check both after the fix.

How do you find the interaction dragging INP down?

Watch the sessions where a visitor clicked and nothing happened. A p75 INP of 640ms says the page is slow; it does not say which control, which route or which device.

Flowsery records the session and flags rage clicks, dead clicks and JavaScript errors automatically, which is what a stalled interaction looks like from the visitor's side: the same button pressed four times because no frame ever painted. Matching sessions group into one issue, issues rank by how many users hit them, and each one lands in Slack, Linear or Jira with the replay and steps to reproduce attached. Collection runs on one script under 10 KB, cookie-free and EU-hosted, with no data sampling, so the slow interactions are not the ones dropped from the sample.

Frequently asked questions

Does INP measure scrolling?

No. Chrome counts mouse clicks, touchscreen taps and key presses, and excludes scrolling, hovering and zooming. A janky scroll is a real complaint that produces no INP sample, so diagnose it through frame timing and long tasks instead.

Why is my INP good in Lighthouse but poor in the field?

Lighthouse runs a scripted interaction on a configured device, and INP scores the worst interaction real visitors made on their own hardware. Your lab run clicks the button you told it to click; your visitors click the expensive filter on a four-year-old Android phone. Treat the lab as a regression check and the field as the verdict.

Should I still track First Input Delay?

No. FID stopped being a Core Web Vital on March 12, 2024, and support ended on September 9, 2024, so it no longer appears in Search Console and carries no weight in the assessment. Move the dashboard panel to INP and keep the FID series only for reading old incidents.

Can one slow click fail the whole page?

Not on its own. The worst interaction becomes that page view's INP, then Google reads the 75th percentile of those values across all page views of the URL. One 3-second click in one session moves nothing; the same slow control hit by a quarter of your sessions fails the URL.

How is INP measured in a single-page app?

INP accumulates for the life of the page, so interactions from one route stay in the same measurement window as the next until a hard navigation resets it. A slow click on a settings screen can be reported against the URL the visitor landed on. Chrome's soft navigation support for splitting those windows is experimental, so segment by route in your own field data.

What per-phase budget keeps INP under 200ms?

Fifty milliseconds of input delay, 50ms of processing duration and 100ms of presentation delay is a workable split. Measure the actual split per route before choosing what to fix, because a handler-heavy search box and a render-heavy product grid fail the same threshold for opposite reasons.

What counts as a long task, and why does it matter for INP?

A long task is any stretch of uninterrupted main-thread work over 50ms, the same threshold the fixes for input delay point to. While a long task runs, the browser cannot start an event handler, so that time adds straight to input delay. Breaking a long task into smaller pieces gives the browser a gap to accept the click and start the handler sooner.

How do you stop layout thrashing from dragging out presentation delay?

Layout thrashing happens when code writes a style and reads it back in the same task, which forces a synchronous layout the browser would otherwise defer. Batch every read before any write in the same task and the forced layout disappears along with the delay it added. Check this first inside presentation delay, ahead of DOM size and content-visibility.

What tool actually measures INP on your own site?

Instrument INP with the web-vitals library or another field collector, read per route. Because INP only reports once real visitors click, tap or type, this number has to come from real user monitoring rather than a single Lighthouse run. Read the result at the 75th percentile, the same way Chrome scores it.

Why does Chrome discard some interactions on pages with a lot of clicks?

Above 50 recorded interactions, Chrome sets aside one high value for every 50 so a handful of outliers cannot decide the whole page's score. A page with 130 interactions discards two of the highest and reports the next one down as its INP. Pages with 50 or fewer skip this step and use the single worst interaction as is.