What is INP and how do you fix it?
INP (Interaction to Next Paint) measures how long your page takes to visibly respond after someone clicks, taps, or types — not just whether the page loaded fast. Google made it an official Core Web Vital in March 2024, replacing First Input Delay (FID). A good INP is 200ms or less; anything over 500ms scores poor.
What does INP actually measure?
INP looks at every interaction a visitor makes on your page — clicks, taps, key presses — and reports a representative value across all of them, not just the first one. For each interaction, it measures the full pipeline: the delay before the browser starts processing the input, how long the actual event handler takes to run, and the delay until the browser paints the next frame showing a visible response. All three stages count toward the final number.
Why did INP replace FID?
FID only measured how long the browser waited before it started processing the very first interaction on a page — it ignored how long that response actually took to finish rendering, and it ignored every interaction after the first. A page could post a great FID and still feel sluggish on every click after the initial one. INP closes both gaps: it accounts for the full response time, and it considers interactions across the entire visit, not just the opening one.
What counts as a good INP score?
Google's official thresholds, per web.dev's INP documentation, are below:
| Rating | INP |
|---|---|
| Good | 200ms or less |
| Needs improvement | Between 200ms and 500ms |
| Poor | Over 500ms |
PageWeight scores INP using these same bands whenever real-user data is available for a scanned URL.
Where does PageWeight's INP number come from?
INP is field data, not lab data — it comes from Google's Chrome UX Report (CrUX), which aggregates real visitor interactions over a rolling 28-day window. That means it only exists for URLs with enough real Chrome traffic to produce a valid sample. For a low-traffic page, PageWeight simply won't show an INP card rather than guess at a number, since there's no way to measure interaction responsiveness in a one-off lab test the way you can measure load metrics like LCP.
What actually causes a slow INP?
Almost always, it's JavaScript keeping the browser's main thread busy at the moment someone interacts:
- Heavy event handlers — a click handler doing expensive work (large DOM updates, unoptimized re-renders) directly delays the next paint.
- Long tasks already running — if the main thread is mid-way through a big script when the click happens, the browser can't respond until that task finishes.
- Third-party scripts — ad networks, chat widgets, and analytics tags competing for the same main thread. See our guide on how third-party scripts slow down your website.
- Layout thrashing — reading and writing to the DOM in a way that forces the browser to recalculate layout repeatedly within a single interaction.
How do you actually fix a bad INP score?
- Break up long JavaScript tasks. Split large synchronous operations into smaller chunks that yield back to the main thread, so a pending click can be handled promptly instead of queuing behind one big task.
- Defer non-critical third-party scripts until after the page's first interaction, rather than loading them eagerly alongside your own code.
- Keep event handlers lean. Move expensive work (large state updates, heavy calculations) out of the direct click/tap handler where possible, or debounce it.
- Reduce total JavaScript shipped to interactive pages generally — less code competing for the main thread means more headroom for a fast response when someone actually interacts.
How do I check my site's INP?
Run a free scan with PageWeight. If your site has enough real-user Chrome traffic, you'll see your current INP alongside the rest of your Core Web Vitals.