What Is INP? Thresholds, Measurement, and How to Fix Slow Interactions
Published:
Last Updated:
Category: Marketing Glossary, Marketing Budget & KPI
Authors: Shusaku Yosa
Interaction to Next Paint, or INP, evaluates how responsively a page reacts to clicks, taps, and keyboard input before the next paint. It is a Core Web Vitals metric: 200 ms or less is good, more than 200 ms through 500 ms needs improvement, and more than 500 ms is poor. Use it to investigate sluggish interaction, rather than loading speed alone.
Know which delay INP measures
INP observes eligible interactions throughout page use, including interactions during loading. Clicks, taps, and keyboard input qualify; scrolling and hovering themselves are not the target. It measures responsiveness to the next paint, not completion of every later network request or business operation. The official INP explanation defines that scope.
A purchase button can promptly display a processing state while payment takes longer to complete. Measure responsiveness and payment completion separately. Conversely, fast networking does not prevent a delayed paint when browser work blocks the response.
Read the thresholds and percentiles correctly
INP value | Assessment | Boundary |
|---|---|---|
200 ms or less | Good | Includes exactly 200 ms |
More than 200 ms, up to 500 ms | Needs improvement | Includes exactly 500 ms |
More than 500 ms | Poor | Must exceed 500 ms |
Within one page visit, INP selects a representative latency rather than averaging all interactions. One highest interaction is disregarded for every 50 interactions. For many visits with fewer interactions, the slowest eligible interaction determines the value.
Field assessment then considers the 75th percentile across page visits, with mobile and desktop evaluated separately. Selecting a representative interaction within a visit and taking a percentile across visits are different steps. One local result below 200 ms does not establish a passing experience for the whole audience.
Combine field evidence with local reproduction
PageSpeed Insights field data comes from CrUX over a rolling 28-day period. If a URL lacks sufficient data, origin-level data may be shown; if that is also insufficient, field data is unavailable. Missing data is not a zero INP or proof of good performance. See the PageSpeed Insights documentation for data scope.
Tool or report | What it reveals | Limitation |
|---|---|---|
PageSpeed Insights field data | A 28-day view of real-user experience | Check sample availability and URL versus origin scope |
Search Console Core Web Vitals | States and trends for similar URL groups | Does not expose the processing behind each slow interaction |
Chrome DevTools Performance | Recorded interactions, work, and rendering | Represents the tested device and conditions |
Standard Lighthouse navigation | Loading issues and indicators such as TBT | Does not replace interaction-based INP testing |
Total Blocking Time can identify blocking work, but it is not INP and cannot be converted into it through a fixed formula. Reproduce actual interactions when investigating responsiveness.
The former Web Vitals Chrome extension is no longer supported following its integration into Chrome 132 DevTools. Follow the Chrome migration guidance and use Performance panel live metrics and recorded interactions.
Reproduce the slow action consistently
- Record the URL, device category, browser, and test date.
- Select important interactions such as navigation, search, forms, or cart actions.
- Test during loading and after loading to identify the problematic state.
- Record the interaction and surrounding work in DevTools.
- Repeat under matching device, CPU-throttling, and action-sequence conditions.
- Separate input delay, processing duration, and presentation delay before proposing a fix.
A fast development laptop can hide problems affecting slower devices. Keep conditions with each result rather than averaging incompatible tests together.
Diagnose the three parts of latency
Phase | Investigate | Possible improvement |
|---|---|---|
Input delay | Existing long tasks and third-party work | Reduce unnecessary work, split long tasks, reconsider priority |
Processing duration | Expensive calculations or synchronous event-handler work | Limit work to what is needed and schedule it appropriately |
Presentation delay | Large DOM updates, style, layout, and rendering | Reduce update scope and avoid unnecessary layout work |
In a fictional local test, 80 ms of input delay plus 100 ms of processing and 60 ms of presentation delay gives 240 ms. After changes, 30 + 50 + 40 gives 120 ms. That demonstrates improvement under those reproduction conditions; it does not establish a public field 75th percentile of 120 ms.
Also verify that faster feedback has not hidden a failed operation. Check processing states, duplicate-submit prevention, and clear success and failure messages across the complete flow.
Validate performance and business outcomes separately
Immediately after release, repeat the local test and check for regressions. Then follow field data as the 28-day window changes. Historical visits remain in that window, so it does not instantly become post-release-only evidence. Record the change date and affected pages, and use suitable real-user monitoring where available.
For prioritization, understand visit reach using the GA4 session specification, then investigate failed or abandoned interactions separately. Good INP can coexist with unclear content or difficult forms. Evaluate outcomes using the conversion improvement process.
Core Web Vitals contribute to search experience, but passing them does not guarantee rankings or sales. Follow Google’s search guidance and combine performance work with content and discovery improvements.
