INP (Interaction to Next Paint) is a Core Web Vitals metric that measures the time between a user interaction — a click, tap, or key press — and the browser painting the visual response. Google made INP an official ranking metric in March 2024, replacing First Input Delay. A score under 200ms is good; over 500ms is poor.
INP is the toughest Core Web Vital to pass for JavaScript-heavy sites. While 65% of sites met the threshold at launch, interactive pages — e-commerce filters, form-heavy SaaS tools, property search sites — regularly fail. Every 100ms of interaction latency costs up to 7% in conversions.
What is INP?
INP stands for Interaction to Next Paint. It measures the end-to-end time from when a user interacts with a web page to when the browser paints the visual response for that interaction. Three phases combine to produce the total INP score:
- Input delay. Time between the user's action and the browser starting to execute event handler code. Caused by the main thread being occupied with other work.
- Processing time. Time to run the event handler itself. Complex JavaScript, DOM mutations, and synchronous API calls all extend this phase.
- Presentation delay. Time between event handler completion and the next frame paint. Heavy CSS, large DOM trees, and expensive layout calculations contribute here.
Google calculates INP at the 98th percentile of interactions during a session — effectively the worst interaction a user experiences, with extreme outliers removed. The score is assessed at the 75th percentile across all real-user sessions for a given URL.
First Input Delay only measured the input delay phase of the first-ever interaction on a page. It ignored processing time, presentation delay, and every subsequent interaction. A site could score well on FID while still delivering a sluggish experience for all its interactive elements. INP closes that gap — it's a full measurement of responsiveness across the entire session.
Why INP matters for SEO and conversions
INP affects two things simultaneously: Google rankings and direct revenue.
- Rankings. INP is a confirmed Core Web Vital and contributes to Google's page experience signal. Poor INP (over 500ms) can put a page at a ranking disadvantage against equally relevant competitors.
- Conversions. A 100ms increase in interaction latency reduces conversion rates by up to 7%. On checkout flows, form submissions, and filter-based product browsing, slow INP directly reduces completed transactions.
- Bounce rates. Pages with INP over 500ms see 32% higher bounce rates. Users interpret slow interactions as broken pages.
- Mobile performance. Mid-range Android devices — the majority of the global web — have significantly less CPU than MacBooks. INP that passes on desktop often fails on mobile, which matters more under Google's mobile-first indexing.
How INP is calculated
INP is measured exclusively from real user interactions — it cannot be fully simulated in lab conditions. The measurement process:
| Interaction type | Counted? | Example |
|---|---|---|
| Mouse click | Yes | Clicking a button, link, or checkbox |
| Touch tap | Yes | Opening a mobile menu, tapping a product card |
| Key press | Yes | Typing in a search field, pressing Enter |
| Scroll | No | Scrolling the page (excluded from INP) |
| Mouse hover | No | Hovering over a nav item (excluded from INP) |
All qualifying interactions are tracked. For sessions with many interactions, Google uses the 98th percentile to report INP — ensuring one edge-case outlier doesn't dominate while still catching chronic slowness.
INP score thresholds explained
Google uses three bands to classify INP scores:
- Good: under 200ms. Interactions feel instant. The visual response appears before users consciously register any lag. Target this range for all interactive pages.
- Needs improvement: 200-500ms. Some users notice a slight lag, especially on slower devices or under CPU load. Interactive features feel slightly sluggish.
- Poor: over 500ms. Interactions feel broken. Half a second of visual latency is long enough for users to assume their tap or click didn't register, leading to double-taps, abandoned forms, and frustrated bounces.
Google assesses Core Web Vitals at the 75th percentile. Targeting under 150ms gives a practical safety buffer to ensure 75% of real sessions score "good" even with natural device and network variance.
INP in practice — three real-world scenarios
Scenario 1: E-commerce filter page — poor INP
A fashion retailer's category page with 14 third-party scripts had 420ms INP when users clicked filter chips. The main thread was occupied processing analytics events. Every filter click had to wait. Fix: deferred non-critical scripts and split the filter event handler into two tasks — one to update the UI immediately, one to fetch filtered results. New INP: 145ms.
Scenario 2: SaaS product tour — good INP
An interactive product tour with animated step transitions scored 118ms INP. The development team had pre-loaded transition assets, used CSS animations instead of JavaScript for visual transitions, and kept event handlers to DOM class toggles only. Result: interactions felt instant across all devices tested.
Scenario 3: Real estate search — mixed INP
The same real estate site scored under 100ms INP on its editorial blog pages and 350ms on its property search. INP is page-specific, not domain-wide. The search page's map integration loaded synchronously, blocking the main thread on every filter interaction. Deferring the maps library until after initial paint reduced INP to 190ms.
INP vs other Core Web Vitals
INP is one of three Core Web Vitals. Each measures a different dimension of user experience.
INP — responsiveness
- Measures interaction delay, not load speed
- Most affected by JavaScript execution
- Good: under 200ms
- Worsens with third-party scripts and large DOM
- Critical for interactive pages (forms, filters, menus)
LCP + CLS — load and stability
- LCP: largest image/text paint time (good: ≤2.5s)
- CLS: layout stability during load (good: ≤0.1)
- Both affect initial page load experience
- INP affects what happens after the page loads
- All three feed into page experience signal equally
INP optimization checklist
- Identify the slowest interactions first. Open Chrome DevTools Performance panel, interact with the page, and look for interactions exceeding 200ms. Fix the worst offenders first — an 80/20 approach works here.
- Break long JavaScript tasks. Any JavaScript task over 50ms blocks event handling. Use
scheduler.yield(),setTimeout(fn, 0), orrequestIdleCallbackto yield between chunks of work. - Defer third-party scripts. Tag manager payloads, chat widgets, and ad scripts should load after the page becomes interactive. Use the
deferattribute or load them in arequestIdleCallback. - Keep DOM size under 1,500 nodes. Large DOM trees cause expensive style recalculations on every interaction. Virtualize long lists; remove hidden elements from the DOM entirely rather than using
display: none. - Update UI before fetching data. Show visual feedback (spinner, disabled state, class toggle) immediately on interaction, then fetch data asynchronously. Users perceive the interaction as instant even if the data takes 300ms to arrive.
- Test on real hardware. DevTools throttling underestimates real-world CPU constraints. Test on a mid-range Android device (Moto G Power or equivalent) to see actual field conditions.
PageSpeed Insights runs in a controlled lab environment. Real users have browser extensions, other tabs running, and lower-powered devices. Lab INP of 150ms can appear as 280ms+ in Google Search Console field data. Always validate improvements using Search Console's Core Web Vitals report — that's what Google's ranking algorithm actually uses.
Common INP mistakes to avoid
- Running everything synchronously in event handlers. DOM queries, data fetching, and complex calculations that happen before the visual update all add to INP processing time.
- Too many third-party scripts. Each script competes for the main thread. Audit every third-party script and remove or defer anything that isn't directly conversion-critical.
- Measuring only at launch. New feature releases, A/B test scripts, and third-party integrations accumulate over time and gradually degrade INP. Set up continuous monitoring.
- Ignoring mobile devices. Desktop INP may be "good" while mobile INP fails. Google's mobile-first indexing means the mobile score is what matters for rankings.
- Treating INP as a one-time fix. INP is a living metric. Continuous performance regression testing is the only way to keep scores stable as a product evolves.
Frequently asked questions
INP stands for Interaction to Next Paint. It is a Core Web Vitals metric that measures the time between a user interacting with a page and the browser painting the visual response. Good INP is under 200 milliseconds.
First Input Delay only measured the input delay on the very first interaction. INP measures all interactions throughout the session — clicks, taps, key presses — and reports the worst-performing one. INP is a harder and more representative metric.
Long JavaScript tasks blocking the main thread are the primary cause. Other contributors: heavy event handlers, too many third-party scripts competing for CPU, large DOM trees that slow style recalculation, and expensive CSS paint operations.
Yes. INP is one of three Core Web Vitals feeding into Google's page experience signal. A poor INP (over 500ms) puts you at a ranking disadvantage against equally relevant competitors. It doesn't override content relevance but is a tiebreaker.
Google Search Console shows site-wide and page-level INP from real users. PageSpeed Insights provides page-level INP with optimization suggestions. Chrome DevTools lets you profile individual interactions and see the three-phase input delay, processing, and presentation breakdown.
Related glossary terms
Sources
