INP (Interaction to Next Paint)
INP (Interaction to Next Paint) is a Core Web Vitals metric that measures a page's overall responsiveness to user interactions, replacing FID in 2024. A good INP score is under 200 milliseconds.
Reviewed by Alexander Yarovenko · Updated: 2026-09-18
What is INP?
INP (Interaction to Next Paint) is a Core Web Vitals metric that replaced First Input Delay (FID) in March 2024. It measures the time from when a user interacts with a page (click, tap, or keyboard input) to the next frame the browser paints — in other words, how quickly the page visually responds to user actions. Unlike FID, which only measured the first interaction, INP measures all interactions throughout the page visit and reports the worst.
INP Thresholds
| INP Score | Assessment |
|---|---|
| Under 200ms | Good |
| 200–500ms | Needs Improvement |
| Over 500ms | Poor |
Why INP Replaced FID
FID only measured delay before the browser began processing the first user interaction — it didn't measure how long the processing actually took. A page could have a good FID but slow response to all subsequent clicks. INP fixes this by:
- Measuring all interactions, not just the first
- Measuring the full time from interaction to visual response
- Better representing real-world interactivity throughout a user session
Common INP Problems and Fixes
- Long tasks on the main thread — JavaScript executing for 50ms+ blocks interactions; use code splitting, defer non-critical JS
- Excessive DOM size — too many DOM elements slows rendering; simplify page structure
- Input handlers that do too much work — move heavy processing out of click/tap handlers; use requestAnimationFrame
- Third-party scripts — ads, analytics, and tracking scripts are frequent INP culprits; audit and remove unnecessary ones
How to use this concept in SEO
INP evaluates the latency of user interactions across a visit. Reduce long main-thread tasks, expensive event handlers, excessive DOM work, and rendering that blocks the next visual response.
Audit checklist
- Confirm that the implementation matches the page purpose and the user task.
- Check the HTTP response, rendered HTML, canonical, robots rules, and internal links together.
- Use Search Console and analytics to verify the result instead of relying on one crawler signal.
- Test a representative URL on mobile and desktop after deployment.
- Document the expected outcome so regressions can be detected in the next audit.
Practical example
A filter click feels slow because one handler recalculates thousands of nodes; the work is reduced, chunked, and the UI acknowledges the interaction immediately.
How to validate the result
Record the current crawl, indexation, performance, and traffic state before changing anything. Recheck the affected template and a representative URL after deployment, then monitor Search Console over the following crawl cycle. A technical change is complete only when the live response and Google’s observed state agree.