Short answer: Interaction to Next Paint (INP) measures how long your page takes to visibly respond to a user's clicks, taps and key presses — across the whole visit, not just the first one. A good score is 200 milliseconds or less at the 75th percentile of real visits. FID, the metric it replaced in March 2024, only measured the delay before the first interaction began processing, which is why so many sites passed it and still felt slow.
What are the current Core Web Vitals thresholds?
- Largest Contentful Paint (LCP): 2.5 seconds or less — how quickly the main content appears.
- Interaction to Next Paint (INP): 200 milliseconds or less — how quickly the page responds to input.
- Cumulative Layout Shift (CLS): 0.1 or less — how much the layout moves around unexpectedly.
All three are judged on field data at the 75th percentile, meaning three quarters of real visits must hit the threshold. Your fast laptop on office wifi is not the test.
Why is INP harder to pass than FID was?
FID measured input delay alone — the gap between a user's first interaction and the browser starting to process it. INP measures the entire round trip for nearly every interaction in the visit: input delay, plus the time your event handlers run, plus the time the browser needs to paint the resulting frame. A page can start fast and still fail INP badly if a filter dropdown blocks the main thread for half a second every time someone uses it.
What causes a bad INP score?
- Long tasks on the main thread. Any single task over 50ms delays every interaction queued behind it.
- Oversized hydration. Shipping an entire React app to the browser to make three buttons interactive is the most common cause we see.
- Third-party scripts. Tag managers, chat widgets, heatmap trackers and ad scripts all compete for the same thread as your event handlers.
- Expensive handlers. Work done synchronously inside a click handler — large re-renders, layout reads and writes interleaved, JSON parsing — is paid for in visible lag.
How do you actually fix it?
Start by cutting how much JavaScript becomes interactive in the first place. In the Next.js App Router, keep components on the server unless they genuinely need browser state; every component you leave server-rendered is hydration work the browser never does. We covered the rendering side of this in our App Router performance guide.
Then attack what remains:
- Break up long tasks. Yield to the main thread between chunks of work so pending interactions get a turn.
- Defer non-essential third parties. Load chat widgets and analytics after interaction, not during page load.
- Keep handlers thin. Update the minimum state needed for visible feedback, then do the heavy work afterwards.
- Animate with CSS, not JavaScript, so animation work runs off the main thread where possible.
How do you measure INP properly?
Lighthouse cannot measure INP directly, because INP needs real interactions from real users. Lighthouse reports Total Blocking Time as a lab proxy. The authoritative source is field data from the Chrome User Experience Report, which you can read in Google Search Console's Core Web Vitals report or in PageSpeed Insights under "Discover what your real users are experiencing". Treat lab tools as a debugging aid and field data as the score.
Does passing Core Web Vitals improve rankings?
Page experience is a genuine but modest ranking signal — it will not lift weak content above strong content. The stronger argument is commercial: slow interaction kills conversion on exactly the elements that make you money, like filters, carts and forms. Fix INP for the revenue, and take the ranking as a bonus.
If you want a diagnosis rather than a score, our web engineering team will trace it to the specific handlers and scripts responsible.