Definition
Interaction to Next Paint measures how quickly a page responds when someone actually uses it — clicks a button, taps a menu, types in a field — from the moment of that input to the next frame the browser paints in response. It watches every eligible interaction across the whole visit and reports (roughly) the worst one. INP is the responsiveness metric among the three Core Web Vitals, and Google’s “good” threshold is 200 milliseconds or less at the 75th percentile of real visits.
INP became an official Core Web Vital on March 12, 2024, replacing First Input Delay (FID). It’s scored from field data in the Chrome User Experience Report, so it reflects real users on real devices rather than a controlled test.
Disambiguation — INP vs. FID: This is the single most important thing to get right, because a lot of older material is now wrong. FID only measured the delay before the browser began processing a user’s first interaction. It ignored how long that interaction actually took to complete, and it looked at only the first one. A page could pass FID and still feel sluggish on every click after the first. INP fixed both gaps: it measures the full cycle through to the visual response, and it looks at all interactions, not just the opening one. If a resource still lists FID as a Core Web Vital, it’s out of date.
Why it matters for marketing
INP is where a site stops feeling like a brochure and starts feeling like a product. The interactions it grades are the ones that carry commercial intent — submitting a form, opening a product filter, adding to cart, expanding an accordion. When those lag, the friction lands precisely on the actions you most want people to complete.
It’s also the strictest of the three vitals and the one many sites still fail, because modern pages ship a lot of JavaScript and the responsiveness cost only shows up under real interaction. For teams that have already tuned loading speed, INP is often the remaining gap between a passing and a failing Core Web Vitals report. B2B sites feel this sharply — long forms, configurators, and multi-step filters are exactly the interaction-heavy patterns INP scrutinizes, and exactly the ones FID used to let slide.
See also: Core Web Vitals (CWV) · Largest Contentful Paint (LCP) · Cumulative Layout Shift (CLS) · AI Overviews
How it works
Every eligible interaction has a measurable latency made of three parts:
- Input delay — the wait before event handlers can run, usually because the main thread is busy with other work.
- Processing time — how long the event handlers themselves take to execute.
- Presentation delay — the time to recalculate layout and paint the next frame that reflects the response.
INP is the latency from input to that next paint. Across a visit, the browser records these for all interactions and reports approximately the worst — for pages with many interactions, it discounts the single worst outlier to stay representative. The recurring villain is the main thread: when it’s clogged with long JavaScript tasks, input can’t be processed and paint can’t happen, and the number climbs.
The threshold
| Rating | INP value (at 75th percentile) |
|---|---|
| Good | ≤ 200 milliseconds |
| Needs improvement | 200 – 500 milliseconds |
| Poor | > 500 milliseconds |
Source: Google Search Central and web.dev (see Sources). Measured from real Chrome users across mobile and desktop.
How to utilize INP
Field data leads. Google Search Console’s Core Web Vitals report shows which URLs fail INP for real users, and PageSpeed Insights surfaces the field score per page. Because INP only appears under interaction, lab tools approximate it with Total Blocking Time (TBT) — a useful lab proxy, though not a substitute for the real field number.
Common use cases:
- Auditing third-party scripts. Chat widgets, analytics, tag managers, and ad libraries run on the main thread and are frequent INP culprits. Measuring INP gives you the evidence to defer, replace, or drop them.
- Tuning interactive components. Product configurators, faceted search, date pickers, and long forms are where INP problems concentrate. Profile the specific interaction that’s slow.
- Governing a design system. Because component behavior propagates across every page built on it, fixing an INP problem in a shared component fixes it site-wide.
Chrome DevTools can record a session and attribute a slow interaction to the exact long task behind it, which turns a vague “the site feels laggy” into a specific function to fix.
Best practices
- Break up long tasks. Split large functions into smaller chunks and yield to the main thread between them (for example, with
await scheduler.yield()), so the browser can respond to input in the gaps. - Ship less JavaScript. The most reliable way to improve INP is to have less code running on the main thread in the first place. Audit bundles, code-split, and remove what isn’t earning its place.
- Defer and prioritize work. Push analytics and logging to the background, and reserve high priority for the updates a user is waiting to see. Scheduler APIs let you say which is which.
- Keep event handlers lean. Do the minimum needed to give visual feedback synchronously, then hand off heavier work asynchronously so the next paint isn’t blocked.
- Audit third-party tags ruthlessly. Every embedded script is a claim on the main thread. Load them where they can’t block interaction, or don’t load them at all.
- Test on mid-range mobile. INP thresholds were calibrated around mid-tier phones, and that’s where you’ll fail first. A flagship device hides the problem.
Future trends
INP is still a relatively young stable metric — it went from experimental to pending in 2023 before becoming a Core Web Vital in 2024 — so tooling and best practices are maturing faster than for the older vitals. Expect richer attribution in field tooling that pinpoints which interaction and which script caused a bad score, closing the long-standing gap between “you failed INP” and “here’s the line of code to fix.”
The pressure only grows as pages get more interactive and more of the UI is assembled at runtime, sometimes by AI-driven personalization. Responsiveness is one thing generative systems can’t paper over: a page either reacts to input quickly or it doesn’t. Fast, responsive pages are also easier for automated agents and answer engines to work through, which ties INP to visibility on newer surfaces like AI Overviews, not just to classic rankings.
FAQs
What is a good INP score? 200 milliseconds or less, at the 75th percentile of real visits. Between 200 and 500 ms needs improvement; above 500 ms is poor.
When did INP replace FID? March 12, 2024. FID was retired as a Core Web Vital on that date. Any guide still treating FID as current is out of date.
How is INP different from FID? FID measured only the input delay of the first interaction. INP measures the full latency — input delay, processing, and presentation — of interactions across the entire visit, and reports the worst. It’s much stricter and far closer to how users actually perceive responsiveness.
What causes poor INP? Long JavaScript tasks blocking the main thread, heavy or inefficient event handlers, and third-party scripts competing for the same thread. The fix almost always involves shipping less JavaScript and breaking up the tasks that remain.
Can I measure INP in a lab? Not directly — INP needs real interactions, so it’s a field metric. Total Blocking Time (TBT) is the lab proxy used to catch likely INP problems before deployment, but confirm with field data.
Why does my INP fail when the page loads fast? Loading speed (LCP) and responsiveness (INP) are different problems. A page can render its content quickly and still choke on interaction if the main thread is busy running scripts. They need separate fixes.
Does INP affect SEO rankings? Yes, as one of the three Core Web Vitals feeding Google’s page experience signals. Like the others, it acts as a tiebreaker between comparable pages rather than overriding content quality.
Which interactions does INP count? Clicks, taps, and keyboard input. Hovers and scrolls don’t count. It records the latency of each eligible interaction and reports approximately the worst across the visit.
Where should I start if I’m failing INP? Profile a slow interaction in Chrome DevTools to find the long task behind it, then audit third-party scripts and break up main-thread work. Those two moves resolve most INP failures.
Related Terms
- Core Web Vitals (CWV)
- Largest Contentful Paint (LCP)
- Cumulative Layout Shift (CLS)
- AI Overviews
- First Input Delay (FID)
- Total Blocking Time (TBT)
- Time to Interactive (TTI)
- JavaScript execution / main thread
- PageSpeed Insights
- Page Experience
Freshness note: INP is a Google-defined metric that replaced FID on March 12, 2024. Its “good” threshold of 200 ms is current as of July 2026 but is set by Google’s Chrome team. Verify against Google Search Central and web.dev before republishing.
Sources
- Google Search Central — Understanding Core Web Vitals and Google search results: https://developers.google.com/search/docs/appearance/core-web-vitals
- web.dev — Interaction to Next Paint (INP): https://web.dev/articles/inp
- web.dev — Optimize Interaction to Next Paint: https://web.dev/articles/optimize-inp