What Is Interaction to Next Paint (INP)?
Interaction to Next Paint (INP) is a Core Web Vital that measures how quickly a web page visually responds to user interactions such as clicks, taps, and key presses. It records the latency of nearly every interaction during a visit and reports a single value near the worst one. A good INP is 200 milliseconds or less, meaning the page consistently paints a visible response fast enough to feel snappy on real devices.
- Good threshold
- 200 ms or less at the 75th percentile (web.dev)
- Needs improvement
- 200 ms to 500 ms (web.dev)
- Replaced
- First Input Delay as a Core Web Vital in March 2024 (Google Search Central)
- What it measures
- Full interaction latency: input delay, processing, and presentation (industry-typical)
What does INP actually measure? #
INP measures responsiveness across a whole page visit, not just one moment. Every time a visitor clicks, taps, or presses a key, the browser records how long it takes from that action until the next frame is painted showing a visible change. That full duration includes three phases: input delay while the browser is busy finishing other work, processing time while your JavaScript event handlers run, and presentation delay while the browser calculates layout and paints the update. INP then reports a single number close to the slowest interaction the user experienced, ignoring rare outliers on pages with many interactions. Because it samples the entire session rather than the first tap, INP captures problems that only surface deep into a visit, such as a sluggish filter on a product list or a slow form submission. For local business sites, that often means booking widgets, menu filters, and quote calculators. Our /services/speed-optimization work targets exactly these interaction bottlenecks. Learn the wider context in /wiki/website-speed-guide.
Why did INP replace First Input Delay? #
First Input Delay (FID) only measured the delay before the browser began processing the very first interaction on a page. It ignored how long your event handlers actually ran and how long the browser took to paint the result. As a result, most sites passed FID easily even when they felt laggy in practice, so the metric flattered slow pages. In March 2024, Google promoted INP to a full Core Web Vital and retired FID. INP fixes those blind spots by measuring the complete interaction, including processing and rendering, and by looking at interactions throughout the visit rather than only the first one. The change raised the bar meaningfully: many sites that comfortably passed FID now show INP problems, especially heavy WordPress builds and single-page apps loaded with third-party scripts. If your site suddenly failed Core Web Vitals in 2024, INP is the likely cause. Our /services/website-rescue and /tools/website-grader can pinpoint whether interaction latency is dragging your scores down.
What is a good INP score? #
Google groups INP into three bands measured at the 75th percentile of real page loads, meaning three out of four visits must meet the target. A good INP is 200 milliseconds or less; visitors in that range perceive interactions as immediate. Between 200 and 500 milliseconds the metric needs improvement, and above 500 milliseconds it is rated poor, with interactions that feel visibly sluggish. The 75th percentile matters because it reflects real users on mid-range phones and imperfect networks, not a fast laptop on office broadband. Field data from the Chrome User Experience Report drives the score that affects search, so lab tools alone will not tell you where you stand. Local service sites often sit in the needs-improvement band because booking tools, chat widgets, and analytics scripts pile up on the main thread. Reaching the good band usually means reducing JavaScript work rather than shrinking images. The /tools/website-grader surfaces your field INP alongside lab diagnostics so you know which band you are in.
What causes poor INP? #
Poor INP almost always comes from too much work happening on the browser's main thread, the single lane where JavaScript, layout, and painting compete. When a visitor taps a button, the browser must finish whatever it is doing before it can run your click handler and paint the result. Long tasks, blocks of JavaScript that run for more than 50 milliseconds without yielding, are the biggest offender because they hold the thread hostage. Common sources on local business sites include bloated page builders, unoptimized third-party scripts like chat widgets and heat maps, large event handlers that recalculate the whole page, and heavy analytics or advertising tags. Excessive DOM size also hurts, because the browser must do more work to update the screen after each interaction. Even a fast server cannot fix INP, since the metric is about client-side responsiveness. Diagnosing it means profiling which scripts run during interactions. Our /services/speed-optimization and /services/care-plans focus on trimming and deferring this main-thread work.
How do you improve INP? #
Improving INP is mostly about doing less JavaScript work when a user interacts, and doing it later. Start by breaking up long tasks so the browser can respond between chunks; techniques include yielding to the main thread with scheduler APIs or splitting big functions. Defer non-essential scripts so they load after interactions rather than blocking them, and remove third-party tags that add no real value. Simplify event handlers so a click does the minimum needed to show a response, deferring heavy calculations. Reducing overall DOM size and avoiding layout thrashing helps the presentation phase paint faster. On WordPress, that often means auditing plugins through /services/wordpress-development and cutting builder bloat. Using web workers to move computation off the main thread can dramatically help data-heavy tools. Because INP is measured from field data, changes take a few weeks to show in reports. Pair fixes with monitoring through /services/care-plans, and validate against real devices rather than only a desktop browser to see genuine gains.
INP versus the other Core Web Vitals #
Core Web Vitals include three metrics, each covering a different part of the experience. Largest Contentful Paint (LCP) measures loading, specifically how long the biggest visible element takes to appear. Cumulative Layout Shift (CLS) measures visual stability, penalizing content that jumps around as the page loads. INP measures responsiveness, how quickly the page reacts once the user starts interacting. They can move independently: a site can load fast yet respond slowly, or feel snappy yet shift layout. That is why optimizing one does not guarantee the others improve. INP tends to be the hardest to fix because it requires trimming JavaScript rather than compressing images, which is a well-understood LCP fix. For a full picture, treat the three together and check them in the same report. Our /services/speed-optimization service tunes all three, and the /wiki/website-speed-guide explains how they interact. You can also see how images and scripts affect loading in /wiki/what-is-render-blocking.
Does INP affect Google rankings? #
Yes, but modestly and indirectly. INP is part of Google's page experience signals, and Core Web Vitals are a confirmed, if lightweight, ranking factor. Google has repeatedly said that relevance and content quality outweigh speed, so a fast page with weak content will not outrank a slow page that answers the query better. Where INP matters most is as a tiebreaker between comparably relevant pages, and as a driver of user behavior: a laggy page frustrates visitors, increases abandonment, and hurts conversions, which can indirectly affect performance. For local businesses competing in the /wiki/what-is-the-map-pack and organic results, a responsive site keeps hard-won visitors engaged through booking and contact steps. In practice, treat INP as a conversion and usability metric first and an SEO metric second. The revenue upside of a snappy quote form usually dwarfs the ranking nudge. Combine INP work with /services/local-seo and /services/conversion-optimization for compounding returns rather than chasing the score alone.
How do you measure INP in the field and lab? #
INP requires two kinds of data. Field data comes from real Chrome users and appears in the Chrome User Experience Report, Google Search Console's Core Web Vitals report, and PageSpeed Insights. This is the data that counts for page experience, because it reflects genuine devices and interactions. Lab data comes from tools that simulate a load in a controlled environment, such as Lighthouse, which cannot fully measure INP because it does not know how a user will interact; instead it reports a related proxy and flags long tasks. To debug INP properly, use Chrome DevTools' Performance panel to record an interaction and see which scripts run, or the web-vitals JavaScript library to log real interactions on your own site. Because field data lags by weeks, changes need patience to confirm. Our /tools/website-grader pulls field metrics where available, and our team uses DevTools profiling during /services/speed-optimization engagements to find the exact handlers slowing your pages.
FAQ
What is a good INP score?
A good INP is 200 milliseconds or less, measured at the 75th percentile of real user visits. Between 200 and 500 milliseconds the metric needs improvement, and anything above 500 milliseconds is rated poor. The 75th percentile means three of every four visits must hit the target, reflecting real phones rather than a fast desktop.
Is INP the same as page load speed?
No. Load speed, captured by Largest Contentful Paint, measures how fast content appears. INP measures how fast the page responds after a user clicks, taps, or types. A page can load quickly yet respond slowly because heavy JavaScript blocks the main thread during interactions, so the two metrics are optimized differently.
When did INP become a Core Web Vital?
INP replaced First Input Delay as a Core Web Vital in March 2024. First Input Delay only measured the delay before the first interaction, while INP measures the full latency of interactions throughout the visit. Many sites that passed First Input Delay now fail INP because it is a stricter, more realistic test.
What is the main cause of poor INP?
Excessive JavaScript on the browser's main thread is the main cause. Long tasks, heavy event handlers, bloated page builders, and third-party scripts like chat widgets and analytics block the browser from responding quickly to clicks and taps. Reducing and deferring that work through speed optimization is the reliable fix.
Can I improve INP without a developer?
You can make simple gains, such as removing unused plugins, cutting non-essential third-party scripts, and choosing a lighter theme. Deeper fixes like breaking up long tasks, deferring handlers, and using web workers usually need developer help. Our /services/speed-optimization service handles these more technical interventions on WordPress and custom builds.
How long until INP changes show up?
Because INP counts in Google's reports as field data from real users, improvements typically take three to four weeks to appear as the Chrome User Experience Report rolls its 28-day window forward. Lab tools like Chrome DevTools show the effect of a fix immediately, so use both to validate progress.
Was this helpful?