TL;DR
INP (Interaction to Next Paint) is the Core Web Vital that measures how fast a page visually responds after someone clicks, taps, or types. A good INP score is 200 milliseconds or less. INP replaced the older FID metric on March 12, 2024, and it matters for both user experience and SEO because it is part of Google’s page experience signals. Fixing INP usually means reducing JavaScript work, taming third-party scripts, and optimizing event handlers, not just compressing images or speeding up load time.
What INP Means: A Plain Definition
INP stands for Interaction to Next Paint. It is one of three Core Web Vitals that Google uses to evaluate real-world user experience. The metric captures how long a page takes to show visual feedback after a user interacts with it, whether that is clicking a button, tapping a menu, or typing into a form.
A page with good INP feels snappy. A page with poor INP feels like it ignores you when you try to use it.
Here is the critical distinction most explanations gloss over: INP is not page speed. A site can load in under two seconds and still fail INP if the JavaScript behind a dropdown menu, filter, or add-to-cart button blocks the browser from painting the next frame. Interaction readiness is different from load speed.
INP watches interactions across the entire page visit and reports a single value that represents the slowest (or near-slowest) interaction, with some outlier handling for pages that receive many inputs. According to Google’s documentation, Chrome usage data shows that 90% of a user’s time on a page is spent after it loads. That is the window INP cares about.
If Search Console or PageSpeed Insights is flagging Core Web Vitals INP problems on your site, the issue lives in what happens after the page appears, not during initial load.
Struggling with technical SEO issues like these? Rankai includes technical SEO fixes in its done-for-you SEO program so you don’t have to guess.
Why INP Matters
The current Core Web Vitals set has three metrics:
- LCP (Largest Contentful Paint) measures loading. How fast does the main content appear?
- INP (Interaction to Next Paint) measures responsiveness. Does the page react when someone uses it?
- CLS (Cumulative Layout Shift) measures visual stability. Does the page jump around unexpectedly?
Google Search Central lists INP alongside LCP and CLS and recommends site owners aim for good scores across all three for both search performance and user experience. For a deeper look at all three metrics together, see this Core Web Vitals guide.
INP matters for three reasons.
User experience. When someone clicks a filter and nothing happens for 600 milliseconds, they click again. Or they leave. Slow interactions frustrate users whether Google measures them or not.
Conversions. The business impact is real. The Economic Times reduced its origin INP from over 1,000 ms to 257 ms and saw a 50% decrease in bounce rate and 43% uplift in pageviews on topic pages. redBus improved INP and reported a 7% increase in overall sales.
SEO. INP is part of Core Web Vitals, and Core Web Vitals are part of Google’s page experience considerations. But Google is clear that good scores do not guarantee top rankings. Content relevance still dominates. Treat INP as a technical health metric that supports strong content, not a shortcut that replaces it.
What Is a Good Core Web Vitals INP Score?
Google defines three INP thresholds, evaluated at the 75th percentile of real page visits:
| INP Score | Status | What It Means |
|---|---|---|
| 0 to 200 ms | Good | The page responds quickly for most users |
| 201 to 500 ms | Needs Improvement | Some users will feel lag on interactions |
| Over 500 ms | Poor | The page likely feels sluggish or broken |
Milliseconds (ms) are thousandths of a second. A 200 ms response is fast enough that most people perceive it as instant. At 500 ms, users start wondering if something is wrong.
One important nuance: Google’s 200 ms threshold is a useful benchmark, but your business threshold might be different. SpeedCurve notes that the impact on conversions varies by site, and the “good” cutoff may not match where your checkout, lead form, or product filters start losing users. If those interactions matter commercially, measure INP against your own conversion data, not just Google’s status label.
How Google Measures INP
INP has two levels of measurement that confuse many site owners.
Within a single page visit, INP typically reports the slowest interaction. For pages with many interactions, there is limited outlier handling so one freak event does not define the score.
Across all users, Google evaluates the 75th percentile of real visits over the past 28 days. This data comes from the Chrome User Experience Report (CrUX), which collects anonymized field data from real Chrome users.
This is why you can test your site once, get a decent result, and still see “Needs Improvement” in Search Console. You tested under ideal conditions. Search Console is looking at what real users experience over time, including users on slow phones, congested networks, and older devices.
Practitioners on Reddit frequently hit this wall. In one thread, a commenter explained that the PageSpeed Insights INP value comes from CrUX data for the domain over the last 28 days, not from the lab test you just ran. They recommended using Chrome DevTools Performance traces to find the actual long tasks causing problems.
Why Your INP Score Seems to Change
Another common frustration: PageSpeed Insights scores that jump from 82 to 46 within minutes. A WordPress community member on Reddit explained that PSI includes both CrUX field data (top of the report) and Lighthouse lab data (bottom of the report). Lab runs vary based on server load, test conditions, and network timing. The field data section is what Google actually uses for ranking signals.
Focus on field data trends, not individual lab runs.
Which Tool to Use When
| Tool | Best For | Limitation |
|---|---|---|
| Google Search Console | Finding affected URL groups | Does not show which interaction is slow |
| PageSpeed Insights | CrUX field data plus lab hints | May lack URL-level data for low-traffic pages |
| Chrome DevTools Performance panel | Reproducing and tracing slow interactions | Requires manual testing |
RUM or web-vitals library |
Identifying real slow interactions and elements | Requires setup |
| Lighthouse | Lab debugging and auditing | Not a replacement for field data |
If Search Console is showing INP issues, start there to identify the scope, then move to more granular tools. For help reading those Search Console reports, this guide on Search Console errors explains what to prioritize.
INP vs FID: What Changed and Why
INP officially replaced First Input Delay (FID) as a Core Web Vital on March 12, 2024. If your last performance audit still mentions FID, it is outdated.
| Metric | What It Measured | Why It Was Not Enough |
|---|---|---|
| FID | Delay before the browser began processing the first interaction only | Too narrow: only one interaction, only input delay, ignored processing and rendering time |
| INP | Full latency from interaction to next paint, across all interactions during the visit | Broader, more realistic measure of how the page actually feels to use |
FID was easy to pass. Cloudflare analyzed sites using real user monitoring and found that 93% of FID values were classified as “good” versus only 75% of INP values. INP is a harder test because it measures more of what actually matters.
The same Cloudflare analysis found that mobile INP is the real problem area: 88% of desktop INP values were good, compared to just 67% on mobile. If your Core Web Vitals INP issues show up only on mobile, you are not alone, but you still need to fix them. For a broader look at mobile optimization, check these mobile SEO best practices.
What Interactions Does INP Count?
INP observes three types of user interaction:
- Mouse clicks (buttons, links, menus, checkboxes, toggles)
- Touchscreen taps (same elements on mobile)
- Keyboard presses (form fields, search inputs, keyboard navigation)
It does not directly count hover effects, pinch-to-zoom, or scrolling. However, scroll-related JavaScript, lazy-load triggers, and intersection observers can still block the main thread and make measured interactions slower as a side effect.
Each measured interaction breaks into three phases:
| Phase | Plain English | Example Problem |
|---|---|---|
| Input delay | The browser is busy before it can respond | A long task from analytics or a JavaScript bundle is running |
| Processing duration | The click handler itself is slow | Filter logic, React re-render, form validation |
| Presentation delay | The page takes too long to draw the result | Large DOM update, layout thrashing, complex CSS recalculation |
Understanding which phase is slow tells you where to look. A high input delay points to background JavaScript. A high processing duration points to the event handler code. A high presentation delay points to rendering work.
Why INP Gets Worse: Common Causes
Poor INP almost always traces back to too much work on the browser’s main thread. Here are the most common culprits, mapped to who typically owns the fix.
| INP Cause | Usually Owned By | What to Check |
|---|---|---|
| Heavy click/tap handlers | Frontend developers | Event callbacks, React/Vue re-renders, form logic |
| Too much JavaScript overall | Engineering | Bundle size, unused code, hydration strategy |
| Tag manager scripts | Marketing/analytics | GTM tags, pixels, event listeners added by tags |
| Ads and embeds | Revenue/ad ops | Ad scripts, iframes, interstitials, video embeds |
| Large DOM and layout thrashing | Frontend/design | DOM size, forced reflows, expensive layout recalculations |
| Plugins and theme scripts | CMS owner | WordPress plugin audit, theme JavaScript, widgets |
| Slow user devices | Product/performance | Mobile segmentation, RUM by device class |
This ownership map matters because the hardest part of fixing INP is often not knowing who to ask. A site owner sees a red number in Search Console and does not know whether to call their SEO, their developer, or their ad vendor.
WordPress and CMS Sites
WordPress users frequently see INP issues without knowing whether the theme, plugins, sidebar widgets, or tracking scripts are responsible. In a Reddit discussion, a WordPress user reported hundreds of posts failing mobile INP and asked whether others using the same theme had the same problem.
The answer is usually: do not blame the theme until you isolate which scripts and interactions are slow. Themes, sidebars, plugins, menus, ad widgets, comment widgets, consent banners, and tag managers can all contribute. A technical SEO audit that includes interaction profiling is the fastest way to narrow it down.
Third-Party Script Bloat
A task exceeding 50 ms is considered a “long task” that can block the main thread. Many third-party scripts create long tasks. Subito’s engineering team described their approach on DEV Community: they isolated GTM, ads, and their own application code through a 1% traffic split. On one page, removing GTM alone dropped INP from 208 ms to 112 ms.
Every third-party script should earn its place. If a pixel, heatmap, or chat widget adds main-thread work that degrades INP on your most important pages, the cost may outweigh the benefit.
How to Diagnose an INP Problem
Do not fix INP by guessing. Follow a structured workflow.
Step 1: Check Search Console. Identify whether the issue is mobile, desktop, or both. Note which URL groups are affected.
Step 2: Open PageSpeed Insights. Look at the field data section (top of the report), not just the lab score. Compare field INP to the thresholds.
Step 3: Segment by page template. Blog posts, product pages, category pages, checkout pages, and landing pages often have different scripts and interaction patterns. A bad INP on product pages might come from filters or add-to-cart handlers that do not exist on blog posts.
Step 4: Reproduce interactions in Chrome DevTools. Open the Performance panel, enable CPU throttling (to simulate mobile), and perform the key interactions: clicking menus, opening filters, submitting forms, tapping navigation links. Look for long tasks.
Step 5: Break the delay into its three phases. Is the problem input delay, processing duration, or presentation delay? This tells you whether background work, event handler code, or rendering is the bottleneck.
Step 6: Audit third-party scripts. Temporarily block chat widgets, ad scripts, GTM tags, heatmaps, and consent banners to isolate their impact.
Step 7: Use RUM for high-value pages. If the affected pages drive revenue, set up real user monitoring with the web-vitals library to capture attribution data like interactionTarget and longestScriptURL. As one practitioner on DEV Community put it, the specific tool matters less than having the right information: which element was clicked and what blocked the main thread.
A practitioner on Reddit recommended this same approach, noting that a single GTmetrix pass does not prove Core Web Vitals are fixed. CrUX takes time to update, so improvements may not appear in Search Console for weeks.
Quick Triage Table
| What You See | Likely Meaning | First Action |
|---|---|---|
| Mobile INP poor, desktop good | Mobile CPU or third-party scripts | Test with CPU throttling, inspect real user data |
| PSI score changes every run | Lab conditions are varying | Focus on field data, not one run |
| INP bad on product/category pages only | Filters, carousels, or scripts on those templates | Trace filter, sort, and add-to-cart interactions |
| INP bad after ads or chat load | Third-party code blocking interactions | Block scripts temporarily or run traffic split |
| INP bad but LCP is good | Site loads fast but reacts slowly | Debug event handlers and main-thread work |
Seeing INP warnings in Search Console and not sure where to start? Rankai’s done-for-you SEO program includes technical SEO execution so you can stop guessing and get fixes implemented.
How to Improve INP
Once you know which phase and which scripts are responsible, the fixes fall into clear categories.
Break Up Long Tasks
Long tasks block the main thread. Google recommends yielding to the main thread so rendering updates and user interactions can happen sooner. Modern browsers support scheduler.yield() as a way to break work into smaller chunks. The practical effect: the browser gets a chance to paint a frame between chunks of JavaScript work.
Reduce Unnecessary JavaScript
Too much JavaScript competes for the main thread. Remove unused code, split bundles so pages only load the JavaScript they need, and replace JavaScript-based solutions with browser-native features where possible (CSS transitions instead of JS animations, for example).
Optimize Event Handlers
If a click handler runs expensive logic before updating the UI, the user waits. Defer non-critical work until after the next frame so visual feedback comes first. For example, update the button state immediately, then run the analytics call or data processing afterward.
Avoid Layout Thrashing
Layout thrashing happens when JavaScript reads layout properties and writes style changes in the same task, forcing the browser to recalculate layout synchronously. Batch your reads and writes instead.
Keep DOM Updates Small
Large DOM trees make rendering expensive. If an interaction triggers a large DOM update (re-rendering a product grid, expanding a mega menu with hundreds of nodes), the presentation delay grows. Minimize what changes on each interaction.
Tame Third-Party Scripts
Defer, lazy-load, or remove third-party scripts that are not essential for the interaction the user is performing. If you run dozens of tracking tags, consider a tag audit. Prioritize scripts that fire on interaction over scripts that load eagerly on every page.
Show Immediate Visual Feedback
Because INP measures time until the next paint, showing a spinner, skeleton screen, or pressed button state can improve both the metric and perceived responsiveness. The browser just needs to paint something that acknowledges the user’s action. DebugBear notes that INP does not care whether the full result is rendered at the next paint, just that a visual update appears.
The “Do Not Overfix” Warning
Fix poor INP. Improve borderline INP on pages that matter commercially. But do not treat a 199 ms INP as meaningfully different from 205 ms if your bigger SEO problem is weak content, poor internal linking, or low authority. As Yoast advises, do not spend dollars to save pennies once the significant issues are resolved. To make sure your on-page fundamentals are solid, run through this on-page SEO checklist.
Does INP Affect SEO Rankings?
Yes, but with important caveats.
INP is part of Core Web Vitals. Core Web Vitals are part of Google’s page experience systems. Google says site owners should aim for good Core Web Vitals for both search and user experience. That makes INP a real signal, not a myth.
But Google also says page experience is not a single ranking factor, and good Core Web Vitals reports do not guarantee top rankings. Relevance, content quality, authority, and intent match still dominate.
The honest answer: fix INP because slow interactions hurt users, leads, and conversions. The SEO benefit is real but indirect. Better page experience supports strong content. It does not make weak content rank.
A LinkedIn practitioner from Digimitrix made a good observation: teams still try to fix “slow websites” by focusing on load-time metrics, while INP exposes problems in JavaScript execution, rendering delays, third-party scripts, and hydration strategies that load-time metrics miss entirely.
To track whether your INP fixes actually move the needle on traffic and conversions, this guide on measuring SEO results walks through the metrics that matter.
Real-World INP Improvements
Three case studies from Google show the business impact of fixing Core Web Vitals INP issues.
redBus improved INP by addressing JavaScript, scroll callbacks, API response sizes, and unnecessary UI re-renders. The result: a 7% increase in overall sales.
Trendyol (a major ecommerce platform) reduced INP by 50% using PageSpeed Insights, Chrome DevTools, and scheduler.yield() to split long tasks. They saw a 1% uplift in click-through rate from product listing pages to product detail pages.
The Economic Times went from an origin INP over 1,000 ms to 257 ms by reducing total blocking time, lazy-loading third-party libraries, removing unused code, shrinking DOM size, migrating parts of the site to Next.js, and offloading heavy computation. The result: 50% decrease in bounce rate and 43% more pageviews on topic pages.
These are not vanity improvements. They tied directly to revenue and engagement metrics.
Common Misconceptions About INP
| Misconception | Reality |
|---|---|
| “INP is just page speed” | INP measures responsiveness after user input, not load speed |
| “If Lighthouse is green, INP is fine” | Lighthouse runs lab tests; Search Console uses real user data |
| “FID and INP are the same thing” | FID measured only the first input delay; INP covers all interactions and includes processing and rendering time |
| “Only buttons matter” | Clicks, taps, and keyboard inputs on any element can trigger poor INP |
| “A fast-loading page cannot have INP problems” | It absolutely can if JavaScript blocks interactions after load |
| “Fixing INP guarantees higher rankings” | It helps page experience, but relevance and content quality still dominate |
| “Only developers can deal with INP” | Non-technical users can identify affected pages, but developers are usually needed for real fixes |
FAQ
What does INP stand for?
INP stands for Interaction to Next Paint. It measures the time from when a user clicks, taps, or types to when the browser shows the next visual update.
Is INP a Core Web Vital?
Yes. INP became a Core Web Vital on March 12, 2024, replacing First Input Delay (FID). It joins LCP and CLS as the three current Core Web Vitals.
What is a good INP score?
A good INP score is 200 milliseconds or less. Scores between 201 and 500 ms need improvement. Scores above 500 ms are classified as poor.
Why did INP replace FID?
FID only measured the delay before the browser started processing the first interaction on a page. It ignored everything after that: the processing time, the rendering time, and every interaction that came later. INP gives a broader, more realistic picture of how a page responds throughout a visit.
Why is my INP bad on mobile but fine on desktop?
Mobile devices have less CPU power, and real users are often on slower phones and networks. Cloudflare’s analysis found that only 67% of mobile INP values were “good” compared to 88% on desktop. Heavy JavaScript, third-party scripts, and large DOM updates hit mobile users harder.
How long does it take for INP fixes to show in Search Console?
Search Console uses CrUX field data collected over a 28-day rolling window. After deploying fixes, it can take several weeks for the data to reflect improvements. Do not expect overnight changes.
Can WordPress plugins cause INP problems?
Yes. Plugins, themes, sidebar widgets, tracking scripts, ad code, consent banners, and page builders all add JavaScript and event listeners that can slow interactions. Isolate the cause by disabling plugins one at a time or profiling interactions in Chrome DevTools.
Should I fix a borderline INP score of 210 ms?
It depends on the page. If it is a high-traffic product page or lead form, even small improvements can affect conversions. If it is a low-traffic informational page and your bigger problems are content gaps or poor authority, spend your time there first.
Core Web Vitals INP problems are a technical SEO issue, not just a “speed” issue. They require identifying the right interactions, the right scripts, and the right people to fix them. If you would rather have experts handle it, Rankai’s flat-monthly SEO program includes technical fixes, content production, and ongoing optimization so nothing falls through the cracks. Learn more about professional search optimization services or book a demo to see how it works.
