Most teams found out about Interaction to Next Paint the hard way: their Core Web Vitals report in Search Console went from all-green to a wall of “needs improvement” URLs overnight in March 2024, and nothing on the site had changed. What changed was the metric. Google retired First Input Delay and promoted INP in its place, and a page that looked responsive under the old, forgiving measurement suddenly looked sluggish under the new, honest one. Understanding what this metric actually captures — and why it is so much harder to pass — is the difference between chasing a green score and genuinely fixing the responsiveness your users feel on every tap.
What Interaction to Next Paint Actually Measures
INP measures how long it takes for the page to visually respond after a user interacts with it — a click, a tap, or a key press. The “next paint” part is literal: the clock starts when you press the button and stops when the browser paints the very next frame that reflects your action. If you tap “add to cart” and the button state, cart count, or loading spinner takes 400ms to appear on screen, that interaction’s latency is roughly 400ms, regardless of whether the network request behind it has finished.
The critical word is all. Over the entire lifespan of a page visit, INP observes every eligible interaction and reports a single representative number — effectively the slowest interaction (for pages with many interactions, it discards a few worst outliers and reports near the high end). This is a “worst-case-you-actually-hit” metric, not an average. One janky menu toggle buried three clicks deep can define your whole score.
INP vs FID: Why the Replacement Was Overdue
The INP vs FID comparison explains why so many sites failed the moment the switch happened. First Input Delay only measured the input delay of the first interaction on the page — the time between the tap and the moment the browser could begin running the event handler. It never measured how long the handler took to run, and it never measured whether the screen actually updated. A site could win FID by doing nothing useful quickly and still feel broken.
INP closes both gaps. It looks at every interaction, not just the first, and it measures the full round trip through to the visible paint. That is why FID was almost always “good” and INP frequently is not: FID graded the easy part of one moment, while INP grades the hard part of every moment. If your INP regressed when nothing else did, this is why.
The Three Phases Inside Every Interaction
To optimize Interaction to Next Paint you have to know where the time goes. Every interaction breaks into three measurable phases, and your fix depends entirely on which one dominates:
- Input delay — the gap between the user’s action and the event handler starting to run. This is almost always the main thread being busy with something else (usually JavaScript executing a long task) when the tap arrives.
- Processing time — how long your event handlers actually take to execute. Heavy state updates, large re-renders, and synchronous work done inside the click handler live here.
- Presentation delay — the time from when your handlers finish to when the browser computes layout, paints, and shows the next frame. Oversized DOMs, expensive CSS, and forced synchronous layout inflate this.
Diagnosing INP without splitting it into these three phases is guesswork. A page whose bottleneck is input delay needs less blocking JavaScript during load; a page whose bottleneck is presentation delay needs a smaller, cheaper DOM. Same score, opposite fixes.
The Thresholds: 200ms Good, 500ms Poor
Google’s thresholds for INP are clear and worth memorizing alongside the other Core Web Vitals. An INP at or below 200 milliseconds is “good.” Between 200ms and 500ms is “needs improvement.” Above 500ms is “poor.” For context, the sibling thresholds are LCP ≤ 2.5s and CLS ≤ 0.1 for a “good” rating. To pass Core Web Vitals overall, the 75th percentile of your real users must fall in the good band for each metric — so it is not enough for the median visitor to be fast; the slower quarter of your traffic has to clear the bar too.
INP Is a Field Metric — Lab Tools Can Only Estimate It
This trips up more teams than any other point. Interaction to Next Paint is fundamentally a field metric: it requires a real human interacting with your page. Lighthouse and other lab tools load the page in a synthetic environment and never click anything, so they cannot produce a true INP — at best they surface diagnostics like Total Blocking Time as a proxy.
The authoritative source is the Chrome User Experience Report (CrUX), which aggregates real Chrome users’ field data. That is what powers the Core Web Vitals report in Google Search Console and the “Discover what your real users are experiencing” panel in PageSpeed Insights. For pages without enough CrUX traffic, or to debug a specific slow interaction, you need Real User Monitoring (RUM) via the web-vitals JavaScript library, which attributes each bad interaction to the exact element and phase. Rule of thumb: use the field (CrUX/GSC) to know whether you have a problem, and RUM plus lab profiling to find what is causing it.
Where INP Problems Actually Come From
Almost every poor INP score traces back to the main thread being blocked when it should be responding to the user. The usual culprits are consistent across sites: heavy third-party scripts (tag managers, analytics, chat widgets, A/B testing tools) executing long tasks; large JavaScript bundles hydrating on load; expensive React or framework re-renders triggered by a single click; unthrottled event handlers firing on every keystroke or scroll; and enormous DOM trees that make each paint expensive. Timers and callbacks scheduled by third parties are a silent, common cause — they run long tasks between interactions, so the user’s tap lands mid-task and waits.
An INP Optimization Playbook, In Priority Order
Effective INP optimization follows a hierarchy — do the high-leverage work first:
- Break up long tasks and yield to the main thread. Any task over 50ms blocks input. Split long-running JavaScript and yield control between chunks so a pending tap can be handled. The modern primitive is
scheduler.yield();await-ing asetTimeout(0)is the compatible fallback. - Defer non-urgent work. Inside a click handler, do only what is needed to paint the response — update the UI first, then schedule the heavy work (network calls, logging, analytics) with
requestIdleCallbackor after the next paint. The user sees a response immediately; the expensive part happens after. - Tame third-party scripts. Audit what runs on the main thread. Load non-critical tags with
async/defer, lazy-load chat and A/B tools, and drop anything that does not earn its cost. - Shrink the render cost. Reduce DOM size, avoid layout thrashing (reading and writing layout properties in a loop), and use CSS
content-visibility: autoto skip rendering off-screen content. This attacks presentation delay directly. - Debounce and throttle. High-frequency handlers (input, scroll, resize) should not run expensive work on every event.
A Worked Example: Update First, Then Do the Heavy Work
Say a “filter” button both toggles an active style and recomputes a 2,000-row table. The naive handler recomputes the table synchronously, so the button’s visual state and the table both wait — processing time balloons and INP lands at 600ms. The fix is to split the work by urgency:
Apply the visual toggle immediately so the button state paints on the next frame, then yield, then run the expensive recompute in the following task. In practice: button.classList.add('active'), then await scheduler.yield(), then rebuildTable(). The user gets an instant acknowledgement — the interaction’s “next paint” happens in well under 200ms — even though the total work is unchanged. INP rewards perceived responsiveness, and perception is set by that first paint after the tap.
Finding Bad INP URLs Automatically
The honest limitation of every desktop crawler and lab tool is that none of them can measure real Interaction to Next Paint — it only exists in field data from actual users. That is exactly the gap SEO Rocket is built to close on the reporting side. Its site audit pulls Core Web Vitals field data (CrUX) for your URLs and flags the pages sitting in the “needs improvement” or “poor” band for INP, LCP, and CLS, so you are not manually clicking through Search Console URL by URL. It also surfaces the lab-side signals that predict INP trouble — heavy render-blocking scripts, oversized pages, and excessive main-thread work — with the likely fix explained next to each finding.
Where a dedicated performance profiler still earns its place is the deep, per-interaction attribution work — a Chrome DevTools performance trace remains the sharpest tool for pinning a single janky handler. SEO Rocket’s job is the continuous, no-setup layer: it watches the whole site’s field metrics across every audit run so a regression like the FID-to-INP switch shows up as a flagged trend instead of a surprise, and it ties that back to the same dashboard as your rank tracking and competitor gap analysis. It is a playbook proven across 1,000,000+ ranking pages: responsiveness is a ranking-adjacent quality signal, and catching a drop early is cheaper than explaining a traffic dip later.
Frequently Asked Questions
Is INP a ranking factor?
INP is part of the Core Web Vitals, which are a real but modest ranking signal within Google’s page experience systems. It is a tiebreaker, not a substitute for relevance and content quality — a fast page with weak content still loses. That said, a genuinely poor INP hurts conversions directly, so it is worth fixing on its own merits regardless of the ranking weight.
Why did my INP get worse when I didn’t change anything?
Almost always because the metric itself changed: INP replaced FID as a Core Web Vital in March 2024, and INP measures the full latency of every interaction rather than just the input delay of the first. Your site did not get slower — it is now being measured honestly for the first time.
How do I measure INP for a single page during development?
Install Google’s web-vitals JavaScript library with attribution, or use the Web Vitals Chrome extension, and interact with the page yourself. Both report INP live and tell you which element and which phase (input delay, processing, or presentation) drove the worst interaction, which is what you need to pick the right fix.
The Bottom Line
Interaction to Next Paint is the metric that finally measures what users mean by “this site feels slow” — the lag between a tap and a visible response, across every interaction, not just the first. Passing it is not about a green badge; it is about keeping your main thread free so the browser can answer the user promptly. Split your long tasks, paint the response before you do the heavy work, and let field data — not a lab score — tell you whether real people are actually getting a fast experience.
