A page can load fast and look ready — then you tap a button and… nothing. A beat later, it finally responds. That lag is exactly what INP measures, and in 2024 it became the third Core Web Vital, replacing the older FID. If your site feels "laggy to use" despite loading quickly, INP is your number.
What INP measures
INP (Interaction to Next Paint) measures how quickly your page responds to user input — taps, clicks, key presses — across the whole visit. Specifically, it looks at the delay between an interaction and the next visual update (paint), and reports a value representing your page's worst-ish responsiveness.
It answers: "When someone interacts with this page, how long until they see something happen?"
INP vs the old FID
INP replaced FID (First Input Delay) for good reason:
| FID (old) | INP (new) | |
|---|---|---|
| Measured | Delay on the first interaction only | Responsiveness across all interactions |
| Captured | Just input delay | The full interaction-to-paint time |
| Realism | Limited | Reflects the whole session |
FID only graded your first impression; INP grades the entire experience — a much fairer measure of how the page actually feels to use.
What counts as good
| INP | Verdict |
|---|---|
| ≤ 200ms | Good |
| 200ms – 500ms | Needs improvement |
| Over 500ms | Poor |
Aim for under 200ms — fast enough that responses feel instant.
What makes INP bad
INP problems are almost always about one thing: the main thread is too busy to respond.
| Cause | What's happening |
|---|---|
| Heavy JavaScript | Long tasks block the thread when the user interacts |
| Too much work on click | A tap triggers expensive synchronous work |
| Large DOM | Updating a huge page is slow |
| Third-party scripts | Ad/analytics scripts hogging the thread |
When the browser's main thread is busy running JavaScript, it can't respond to the tap until it's free — that's the delay INP captures.
How to improve it
- Ship less JavaScript. The less there is to run, the freer the thread. Code-split and remove what you don't need.
- Break up long tasks. Split big chunks of work so the browser can respond to input between them (yielding to the main thread).
- Do less on interaction. Defer non-urgent work after the visual response — update the UI first, do the heavy lifting after.
- Tame third-party scripts. Load them so they don't block interactions.
- Keep the DOM reasonable. Smaller, simpler pages update faster.
The core idea: INP is a main-thread availability problem. Anything that frees the main thread to respond quickly — less JS, smaller tasks, less work on click — improves it.
The bottom line
| In one line | |
|---|---|
| What | How fast the page responds to interactions, all visit long. |
| Replaced | FID — INP measures every interaction, not just the first. |
| Good | Under 200ms. |
| Fix | Less JavaScript, break up long tasks, do less on click. |
INP is the vital that captures "does this feel snappy?" — and the answer is mostly about keeping the main thread free. Trim your JavaScript, break up the heavy work, and your page responds the instant users touch it.
Related: Core Web Vitals explained, how to speed up your website; test with the free Core Web Vitals checker.