A good INP score is 200 milliseconds or less, measured at the 75th percentile of real visits. Between 200 and 500 ms the page “needs improvement”, and above 500 ms it is rated poor. Google applies these thresholds separately to mobile and desktop, so a page can pass on one and fail on the other.
Interaction to Next Paint (INP) measures how quickly a page responds visually after someone clicks, taps or presses a key. It became a Core Web Vital on 12 March 2024, replacing First Input Delay (FID), which only measured the delay before the first interaction was handled. INP looks at the interactions across the whole visit and reports one of the slowest.
In practice, “good” means three things: at least 75% of real visits get a response within 200 ms, you are measuring with field data rather than a single lab test, and you have some headroom below the line so a new script or a busy sale week does not push you over it.
This guide explains how the score is calculated, where to find yours, why some tools show nothing, and how to diagnose and fix a slow INP without guessing.
What are the INP thresholds?
Google uses three bands, and the boundary values matter. The table below reflects web.dev’s INP documentation and the Search Console Core Web Vitals report.
| Rating | INP value | What it means for users |
|---|---|---|
| Good | 200 ms or less | Clicks and taps feel immediate for most visits |
| Needs improvement | Above 200 ms, up to 500 ms | Noticeable lag on menus, filters, forms or add to cart |
| Poor | Above 500 ms | Users repeat clicks, think the page is broken or leave |
Is exactly 200 ms good? Yes. web.dev defines good as “below or at” 200 ms, so 200 passes and 201 does not. The same logic applies at 500 ms: exactly 500 still counts as needs improvement, and anything above it is poor.
For comparison, the other two Core Web Vitals in Search Console use LCP thresholds of 2.5 s and 4 s and CLS thresholds of 0.1 and 0.25. INP is the only one measured in milliseconds of responsiveness rather than loading or visual stability.
How is your INP score actually calculated?
INP is calculated per visit first, then summarized across visits at the 75th percentile. Understanding both steps explains most of the confusion people have with the number.
During one visit, the browser times every click, tap and key press. Each interaction has three parts:
- Input delay: the wait before your event handlers start, usually because the main thread is busy with other work.
- Processing duration: the time your event handlers take to run.
- Presentation delay: the time from the handlers finishing until the browser paints the next frame.
The visit’s INP is the longest of those interactions, with one exception for busy pages: web.dev states that one highest interaction is ignored for every 50 interactions, so a single freak spike on a long session does not define the score. Hovering, scrolling and zooming are not counted as interactions.
Then the values from all visits are pooled, and the 75th percentile is reported. That is the “75% rule”: your page is good if at least three out of four visits had an INP of 200 ms or less. The remaining quarter can be slower without failing the page, which is why fixing your typical slowest interaction matters more than chasing a rare edge case.
A visit where the user never clicks, taps or types produces no INP value at all. Pages that people mostly read, such as long articles, often have less INP data than pages people operate, such as category filters or checkout.
Is a good INP score different on mobile and desktop?
The threshold is the same, 200 ms, but the results are very different. Phones have slower processors, so the same JavaScript takes longer to run, and Google reports mobile and desktop separately in both PageSpeed Insights and Search Console.
The HTTP Archive’s 2024 Web Almanac performance chapter found that 74% of mobile websites and 97% of desktop websites had good INP. In other words, INP is mostly a mobile problem. If your desktop report is green and your mobile report is amber, that is the normal pattern, not a measurement error.
Prioritize the device that brings your traffic and revenue. For most consumer sites that is mobile, which also means testing on a mid-range Android phone or with CPU throttling in Chrome DevTools, not on a fast laptop. Our mobile SEO guide covers the wider mobile picture.
Where can you check your INP score?
Use field data to know whether you pass, and lab tools to find out why you do not. Each tool answers a different question.
| Tool | Data type | Best used for |
|---|---|---|
| Search Console, Core Web Vitals report | Field (CrUX), grouped URLs | Seeing which groups of pages fail on mobile or desktop, and validating fixes |
| PageSpeed Insights | Field (CrUX, previous 28 days) plus Lighthouse lab test | Checking one URL or the whole origin quickly |
| CrUX API, BigQuery or CrUX Vis | Field (CrUX) | Trends over time and comparisons with competitors |
| Real user monitoring (RUM), for example the web-vitals JavaScript library | Field, your own visitors | Finding which element and interaction caused a slow INP |
| Chrome DevTools Performance panel | Lab | Recording an interaction and seeing which task blocked it |
| Lighthouse (navigation mode) | Lab | Total Blocking Time as a rough proxy; it does not measure INP during a page load test |
Google’s own documentation is clear about the hierarchy: field data from real users is the best way to measure INP. Total Blocking Time can hint at problems, but web.dev describes it as a reasonable proxy, “not a substitute for INP”. A perfect Lighthouse score does not mean you pass INP.
Why does PageSpeed Insights show no INP score for some pages?
Usually because there is not enough real-user data for that URL. PageSpeed Insights pulls field data from the Chrome UX Report (CrUX), which only includes pages that are publicly discoverable and have enough visitors. Google does not publish the exact traffic threshold.
When a single URL lacks data, PageSpeed Insights tries to fall back to origin-level data, meaning your whole domain. If the origin also lacks data, the field section shows “No Data”, and only the Lighthouse lab results remain. Other common reasons:
- The page is new, so it has not yet collected 28 days of visits
- The page is behind a login or blocked from indexing, so CrUX does not include it
- Visitors rarely interact with the page, so there are few INP samples even with good traffic
The practical fix is to add your own RUM. The web-vitals library’s onINP function reports INP from every visit, and its attribution build tells you which element was involved and how long each of the three phases took. That gives you data on low-traffic pages and, more importantly, the context to debug.
How do you find what makes INP slow?
Diagnose the phase first, then the cause. Each phase points to a different kind of fix.
| Slow phase | Typical cause | Where to look |
|---|---|---|
| Input delay | Main thread busy with other scripts: tag managers, chat widgets, A/B testing, heavy hydration during load | Long tasks in DevTools around the moment of the click |
| Processing duration | Event handler does too much: filtering a large product list, analytics calls, synchronous storage, re-rendering whole components | The click or keydown handler in the Performance panel |
| Presentation delay | Large DOM, expensive style and layout recalculation, rendering big chunks of HTML with JavaScript | “Recalculate Style” and “Layout” entries after the handler |
A simple workflow:
- In Search Console, find the URL groups with “INP issue” on mobile.
- Open one example URL and identify the interactions people actually perform: the menu, a filter, the size selector, add to cart, a form field.
- In Chrome DevTools, set CPU throttling, start a Performance recording, perform the interaction, and stop.
- Look for long tasks, which web.dev defines as tasks over 50 ms, and note which script they come from.
- Repeat the interaction while the page is still loading. The main thread is often busiest then, and that is when real users click.
How do you improve a poor INP score?
Do less work on the main thread at the moment of interaction, and give the browser a chance to paint sooner. The fixes below are ordered roughly from easiest to most technical.
Audit third-party scripts first
On many marketing sites, the biggest INP cost is not your code. Chat widgets, heatmaps, consent tools, review widgets and several analytics tags all compete for the main thread. List every script in your tag manager, remove what nobody uses, and delay non-essential tags until after the page has loaded or after the first interaction.
Show feedback first, then do the rest
Update the interface immediately (open the menu, show the spinner, mark the button as pressed), then run the slower work in a separate task. This is called yielding to the main thread. A small helper like the one below uses scheduler.yield() where the browser supports it and falls back to setTimeout elsewhere:
function yieldToMain() {
if (globalThis.scheduler?.yield) {
return scheduler.yield();
}
return new Promise(resolve => setTimeout(resolve, 0));
}
button.addEventListener('click', async () => {
showFilterResultsLoading(); // visible update first
await yieldToMain(); // let the browser paint
applyFilters(); // heavier work afterwards
sendAnalyticsEvent();
});According to web.dev, scheduler.yield() is supported in Chrome and Edge from version 129 and Firefox from version 142, but not in Safari, which is why the fallback matters.
Break up long tasks
Any task longer than 50 ms blocks input. Split long loops, such as processing hundreds of products, into chunks with a yield between them. Ask your developer to review hydration in JavaScript frameworks, which often runs as one large task during load.
Keep the DOM lean
Every extra element makes style and layout recalculation slower. Paginate or virtualize long lists, remove hidden duplicate menus for mobile and desktop, and use the CSS content-visibility property to skip rendering of off-screen sections.
Avoid layout thrashing
Reading a layout value, such as an element’s height, right after changing styles forces the browser to calculate layout immediately. Group reads before writes in your event handlers.
Re-check after each change
Field data takes time to move. CrUX in PageSpeed Insights covers the previous 28 days, and Search Console’s validation runs a 28-day monitoring window. Use your own RUM to confirm the fix within days, then let Google’s reports catch up.
Does INP affect SEO rankings?
INP is part of Core Web Vitals, which Google says aligns with what its core ranking systems seek to reward, but it is not a shortcut to the top of the results. Google “highly recommends” good Core Web Vitals for success in Search, while relevance and content quality remain decisive.
The stronger case for fixing INP is commercial. Slow filters, laggy add-to-cart buttons and unresponsive forms cost conversions directly, especially on mobile. Treat a good INP score as a baseline for a usable site, then put the bulk of your SEO effort into content and structure. Our ecommerce SEO guide shows where performance fits in a store’s priorities.
What should you aim for?
Aim for a 75th percentile INP comfortably below 200 ms on mobile, not just under it. A page at 190 ms passes today but can fail after one new marketing tag or a traffic spike from slower devices. A buffer of several tens of milliseconds gives your team room to add features.
Set targets per template rather than per URL: category pages, product pages, articles, forms and checkout. Fix the template with the most traffic and the worst INP first, and make INP part of the release checklist so new scripts are reviewed before they go live.
Where does Marketer Coffee fit?
Marketer Coffee is an AI SEO and GEO agency; we treat performance as part of technical SEO, alongside architecture, structured data and content. Results from other industries:
- Aldi.pl (retail). Organic clicks rose from 367,127 to 852,724 a month in 12 months (+132%) with product content, Product schema, a leaner architecture and unified store data. Read the Aldi case study.
- IDG-Online (CCTV services and affiliate). From 500 to 30,000+ monthly clicks in 16 months against Ceneo, MediaExpert and MediaMarkt, with ranking pages, Q&A content and schema. Read the IDG-Online case study.
Who we fit: sites where speed, structure and content need one plan, often stores or international sites. Who we do not fit: teams that only need a JavaScript performance engineer for a one-off framework rewrite; hire a specialist developer for that. To see how your site performs in AI search as well as Google, start with our free AI visibility audit.
Frequently asked questions about INP scores
What is a good INP score?
200 milliseconds or less at the 75th percentile of real page visits, measured separately for mobile and desktop. Above 200 ms and up to 500 ms needs improvement; above 500 ms is poor.
When did INP replace FID?
INP became a Core Web Vital on 12 March 2024, replacing First Input Delay. Search Console removed FID on that date.
Why is my INP good on desktop but poor on mobile?
Phones have slower processors, so the same scripts take longer to run. The 2024 Web Almanac found good INP on 97% of desktop websites but only 74% of mobile websites.
Can Lighthouse measure INP?
A standard Lighthouse page load test does not include user interactions, so it cannot report INP. It shows Total Blocking Time, which is a rough proxy. Use field data from CrUX or your own RUM to judge INP.
How long does it take for an INP fix to show in Search Console?
Field data covers a rolling 28-day window, and Search Console validation monitors for 28 days, so expect about four weeks before reports fully reflect a fix. Your own RUM can confirm it sooner.
What is the short version?
Good INP is 200 ms or less for at least 75% of real visits, on each device type. Find failing templates in Search Console, record the slow interactions in DevTools, decide which phase is slow, and fix the cause: fewer third-party scripts, faster feedback, shorter tasks and a smaller DOM. Then leave yourself a buffer.
If you want a second opinion on where performance sits among your SEO priorities, Book a free consultation.
Sources: web.dev, “Interaction to Next Paint (INP)” (thresholds, 75th percentile, interaction phases, outlier rule, TBT as proxy); web.dev blog post by Jeremy Wagner and Rick Viscomi announcing INP as a Core Web Vital on 12 March 2024; web.dev, “Optimize Interaction to Next Paint” and “Optimize long tasks” (50 ms long tasks, scheduler.yield support); Google Search Console Help, Core Web Vitals report (thresholds, 28-day validation); Google Search Central, “Understanding Core Web Vitals and Google search results”; Chrome for Developers, CrUX methodology and CrUX in PageSpeed Insights (eligibility, 28-day window, origin fallback); HTTP Archive, Web Almanac 2024, Performance chapter; Marketer Coffee, Aldi and IDG-Online case studies (other industries).
