Interaction to Next Paint, or INP, is the wait between a tap and the moment the screen changes. It scores how fast your page answers a finger, not how fast the page showed up. Google calls 200 milliseconds or less good, and anything over 500 milliseconds poor.
What the number actually measures
Google’s page on the metric was published 6 May 2022 and last updated 2 September 2025. It says INP watches every click, tap and key press across a whole visit, then reports a single value that all, or nearly all, of those interactions came in under.
The cutoffs are exact. At or under 200 milliseconds is good. Above 200 and up to 500 is “needs improvement.” Above 500 is poor. The score is read at the 75th percentile of page views recorded in the field, and phones and desktops are counted apart.
One more rule matters on a busy page. For every 50 interactions, the single highest one gets thrown out. Google’s page adds that most visits never get past 50 interactions at all, so on a small site the worst tap usually is the score.
That is the whole idea. Not how fast your page arrives. How fast it answers.
Why a fast page can still feel slow
Load speed is about pixels arriving. INP is about the page replying.
Picture a homeowner on your site at nine at night with water on the floor. The page is already up. He taps the menu. Nothing moves. He taps again. Now the menu opens and closes, and he is back where he started. No load speed test will ever show you that moment.
Google’s guide to fixing INP, published 19 May 2023 and last updated 2 September 2025, splits a single tap into three parts:
- Input delay: from his finger hitting the glass to the code for that tap starting to run.
- Processing duration: that code running to the end.
- Presentation delay: from the code finishing to the browser drawing the next frame on screen.
A browser page does nearly all of this on one main thread. One lane. If something else is already working in that lane, the tap waits its turn. Google’s guide points at page startup as a common cause, and says plainly that a page having rendered does not mean the page has finished loading, while scripts are still being read, compiled and run.
That is the answer to the question in the title. Your site looks done. The lane is still busy.
Every tool bolted onto a page gets a turn in that lane. Live chat is one of them, and that has its own math.
What counts as an interaction, and what does not
Google’s page lists three kinds and only three: a click with a mouse, a tap on a device with a touchscreen, and a key press on a physical or onscreen keyboard.
Hovering, zooming and scrolling are not counted. If your page stutters while somebody scrolls your service list, that is a real problem, but it is not the one this number reports.
MDN’s glossary entry, last modified 14 January 2026, adds a limit worth knowing. It says network fetches and file reads usually do not delay INP, since painting can happen while the browser waits on them. So a contact form that spins for three seconds waiting on a server is a slow form. It is not automatically a bad INP score, and where that form sends the lead is the thing to check. Those two get confused a lot.
When Google started counting this
INP replaced First Input Delay as a Core Web Vital on 12 March 2024. Google’s web.dev post announcing it, written by Jeremy Wagner and Rick Viscomi, carries no publish date, only a last update of 31 January 2024. It said First Input Delay would come out of Google Search Console the day INP took over, and that other tools, PageSpeed Insights and Google’s real user report among them, would carry it for six more months so developers could update their code.
So if a marketing company hands you an audit grading your “First Input Delay,” check when it was written. That older metric only measured the wait before the browser could start handling the very first tap, and nothing after it. Ask for a current report.
Does any of this move you in search results? Google Search Central’s page experience document, last updated 10 December 2025, says “Core Web Vitals are used by our ranking systems.” Read the rest of that page before somebody quotes it at you. The same page says “Google Search always seeks to show the most relevant content, even if the page experience is sub-par,” and that beyond Core Web Vitals, other page experience aspects do not directly help a page rank higher. Google does not publish how much weight any of it carries. Nobody selling search checks can tell you either, so be careful with anyone who puts a number on it.
Most sites already pass this one
Here is a figure you can go and check yourself. The HTTP Archive Web Almanac’s 2025 performance chapter, published 15 January 2026 and built on measurements from July 2025, found 77% of sites had a good INP on phones. On desktop it was 97%.
Put that next to all three Core Web Vitals together. On phones, 48% of sites passed. On desktop, 56%. Loading is the harder half of the test. Responsiveness, for most sites, is already fine.
So here is the honest version for a plumber, a roofer or an electrician. You probably do not have an INP problem. If your site is a handful of pages with a phone number, a form and photos of finished work, this is not where your money should go. Do not let anyone sell you an INP fix without first showing you your own number from real visitors.
Getting that number is its own hurdle. Google’s real user data only covers pages that get enough visits from Chrome users, and plenty of local trade sites never reach that bar, which is why the top of your report can come up empty.
What to do next
Plain steps, in order:
- Open PageSpeed Insights and enter your own page address. Look at the real user section at the top of the report, not the lab score below it. Find INP.
- If there is no real user data, test by hand. Use your own phone on cell service, not the office wifi. Tap the call button. Open the menu. Tap into the form. Count the wait each time. Half a second is obvious once you look for it.
- Write down every script running on the site: chat, booking, review sliders, tracking tags, popups, map embeds. Ask what each one has earned this year.
- Remove the ones nobody uses. A page never gets faster by adding.
- Test again after a few weeks of real visits, since the field number moves slowly.
If the site is old enough that nobody knows what half those scripts do, rebuilding may cost less than auditing. How a build works covers what that involves, and the monthly plans are listed on the pricing page.