← All posts
Core Web Vitals · Performance

INP, the Core Web Vital that replaced FID: what it is and how to pass it

Interaction to Next Paint, or INP, is the Core Web Vital that replaced First Input Delay. First Input Delay only measured the delay before the first interaction was handled, but INP measures how quickly a page responds to all of the interactions it supports across a visit, which includes clicks, taps and key presses, and it reports a value that is close to the slowest of them (see Google's INP guide). This means a page that passed First Input Delay can still fail INP.

LCPLargest Contentful Paint
INPInteraction to Next Paint
CLSCumulative Layout Shift

The bands mark Google's good, needs-work and poor thresholds; the marker is a sample site.

The three Core Web Vitals and the thresholds that Google uses. INP is measured in milliseconds, so 200ms or less is good, and anything over 500ms is poor.

What INP actually measures

Every time a user taps, clicks or presses a key, the browser has to respond and paint the result. INP records how long that takes, from the interaction to the next frame the user sees, and reports a value near the worst interaction of the visit. The Core Web Vitals field assessment measures INP on real users at the 75th percentile, which means it reflects the devices that people actually use. Lab tools can reproduce a single interaction, but a test that only measures the page load does not capture the whole experience.

The usual causes of a bad INP

  • Long JavaScript tasks that block the main thread, so the browser cannot respond to the tap until the script finishes.
  • Heavy event handlers that do too much synchronous work in response to a click.
  • Third-party scripts (tag managers, chat widgets, ad tech) holding the main thread at the moment a user interacts.
  • Large, complex DOM updates that take a long time to render after the interaction.

How to improve it

  1. Break up long JavaScript tasks so the main thread is free to respond between chunks.
  2. Defer or lazy-load non-critical third-party scripts, especially anything that runs on load.
  3. Keep event handlers light: do the minimum synchronously, and push the rest to an idle callback.
  4. Simplify the work an interaction triggers, so the next paint arrives quickly.

INP FAQ

What is a good INP score?

200 milliseconds or less is good, over 200 and up to 500 needs improvement, and over 500 is poor, according to Google's INP guide. The field assessment uses the 75th percentile of the interactions that real users have across a visit.

Why did Google replace FID with INP?

FID only measured the first interaction's delay and was easy to pass while a page still felt sluggish later. INP measures responsiveness across the whole visit, which matches what users actually experience.

How do I measure INP on my own site?

Start with the field data in the Core Web Vitals report, or with a tool that reads it. Auditaar reports INP from real-user field data wherever that data exists, and it highlights the render-blocking and third-party work that you can look into as possible causes.

Auditaar reads INP from real-user field data wherever that data exists, and when a page is slow it highlights the render-blocking and third-party work that you can look into. Run an audit, or read how to read a website audit.

See it on your own site

Auditaar turns a single URL into a scored, sourced, ordered plan across all six pillars, AI Visibility included.

Related reading