What is a good INP score?

A good INP is 200 ms or less, measured at the 75th percentile of real user interactions. Between 200 ms and 500 ms needs improvement, and anything over 500 ms is rated poor. A page must also pass LCP (2.5 s or less) and CLS (0.1 or less) to have good Core Web Vitals overall.

Did INP replace First Input Delay (FID)?

Yes. INP became a stable Core Web Vital and replaced First Input Delay (FID) in March 2024. FID only measured the delay before the first interaction was processed, while INP assesses the responsiveness of interactions throughout the whole visit, making it a stricter and more representative signal.

What causes a poor INP?

Poor INP is usually caused by long tasks blocking the browser's main thread, often from heavy or third-party JavaScript, expensive event handlers, or large rendering work. Because the main thread is busy, the browser cannot paint the response to a tap or click quickly, which pushes the measured interaction time up.

INP is a field metric, so it is best measured from real visitor sessions rather than a single lab run. Real user monitoring collects interaction timings in the browser across the devices and networks people actually use, then reports the value at the 75th percentile, which reflects the experience of the slower quarter of visits.

What Is INP (Interaction to Next Paint)?

Reviewed by Ionut Caval · Updated June 2026

INP (Interaction to Next Paint) is the Core Web Vital that measures how quickly a page responds to user interactions, recording the delay between an action such as a tap or click and the next frame the browser paints in response. A "good" INP is 200 ms or less at the 75th percentile of real visits.

INP is one of the three Core Web Vitals Google uses to judge page experience, and it is the one focused on responsiveness. Rather than timing a single moment, INP watches every interaction during a visit (clicks, taps, and key presses) and reports a value near the slowest one, so a page that feels snappy at first but stalls on a later button press is still penalised. The score is the time from the interaction until the browser renders the next visual update, which is the first frame where the user sees that something happened.

INP thresholds and how it is scored

Google groups INP into three bands, measured at the 75th percentile of page loads from real visitors so that the worst quarter of experiences cannot be hidden by a fast average:

Good: 200 ms or less.
Needs improvement: between 200 ms and 500 ms.
Poor: over 500 ms.

INP sits alongside the other two vitals, each with its own target at the 75th percentile: LCP (Largest Contentful Paint) at 2.5 seconds or less for loading, and CLS (Cumulative Layout Shift) at 0.1 or less for visual stability. A page needs to pass all three to count as having good Core Web Vitals.

What causes poor INP, and how to measure it

Slow INP almost always traces back to the main thread being blocked. When a long JavaScript task is running (event handlers, hydration, third-party scripts, or heavy rendering work), the browser cannot paint the response to a click until that task finishes. The usual fixes are to break long tasks into smaller chunks, defer or remove non-essential scripts, and avoid large synchronous work on interaction. Because INP depends on what real users actually do on real devices, it can only be measured accurately in the field, which is the job of real user monitoring rather than a single lab test. Field RUM and scheduled lab checks answer different questions, a distinction covered in synthetic monitoring vs real user monitoring. Responsiveness data complements availability data from external checks such as Pulsetic's uptime and API monitoring, which confirms the page is up and fast to respond at the network level.

Frequently asked questions

What is a good INP score?

A good INP is 200 ms or less, measured at the 75th percentile of real user interactions. Between 200 ms and 500 ms needs improvement, and anything over 500 ms is rated poor. A page must also pass LCP (2.5 s or less) and CLS (0.1 or less) to have good Core Web Vitals overall.
Did INP replace First Input Delay (FID)?

Yes. INP became a stable Core Web Vital and replaced First Input Delay (FID) in March 2024. FID only measured the delay before the first interaction was processed, while INP assesses the responsiveness of interactions throughout the whole visit, making it a stricter and more representative signal.
What causes a poor INP?

Poor INP is usually caused by long tasks blocking the browser's main thread, often from heavy or third-party JavaScript, expensive event handlers, or large rendering work. Because the main thread is busy, the browser cannot paint the response to a tap or click quickly, which pushes the measured interaction time up.
How is INP measured?

INP is a field metric, so it is best measured from real visitor sessions rather than a single lab run. Real user monitoring collects interaction timings in the browser across the devices and networks people actually use, then reports the value at the 75th percentile, which reflects the experience of the slower quarter of visits.

Put these metrics to work. Monitor your site free.

2-minute setup · Cancel any time
Create Free Account

Your Dashboard

No credit card needed