Core Web Vitals & INP Checker

INP Test: How to Check Interaction to Next Paint

An INP test answers two different questions. Field data tells you how the page actually performed for real Chrome visitors over the last 28 days; lab data tells you what a single controlled Lighthouse run measured right now, including the long tasks and scripts that delayed the interaction.

1. Test the URL your visitors actually land on. A homepage score does not describe a product or checkout page with different JavaScript.
2. Check field data first. If CrUX has enough traffic for the URL, that is the number Google uses. If it does not, treat the lab run as a diagnostic, not a ranking signal.
3. Find the interaction, not just the score. The lab run attributes INP to long tasks, third-party scripts, hydration, or a large DOM; the fix depends on which one is responsible.
4. Re-test after the change. Ship one fix at a time and compare the same URL and strategy, or the two runs are not comparable.

What is a good INP score?

Google's thresholds are 200 milliseconds or less for good, 200–500 milliseconds for needs improvement, and above 500 milliseconds for poor. The threshold applies to the 75th percentile of real-user interactions, not to a single lab run, so one slow click in a Lighthouse trace does not by itself mean the page fails.

INP vs FID

First Input Delay measured only the delay before the browser could start handling the first interaction. INP measures the full latency of every interaction — input delay, processing time, and presentation delay — and reports a high percentile rather than the first click. A page can pass FID and still fail INP because the main thread is busy long after the first input.

For the metric definitions and the wider page-experience picture, see the Core Web Vitals guide and the Interaction to Next Paint glossary entry.