What Is INP (Interaction to Next Paint) and How Do You Fix It?
INP measures how quickly your page responds when someone clicks, taps, or types. Learn what counts as a good INP, why it replaced First Input Delay, what causes a poor score, and how to find the slow interactions on your own site.
Short answer: INP is a Core Web Vital that measures the delay between a user's interaction and the next visual update on the page. A good INP is 200 milliseconds or less. Above 500 milliseconds is poor. It replaced First Input Delay as a Core Web Vital in March 2024.
Table of Contents
- What INP Measures
- INP Thresholds
- INP vs FID
- What a Poor INP Feels Like
- Common Causes
- How to Find Slow Interactions
- How to Improve INP
- Key Takeaways
What INP Measures
When someone clicks, taps, or presses a key, three things happen before they see a result:
- Input delay. The browser is busy with other work and cannot start handling the interaction.
- Processing time. Your event handlers run.
- Presentation delay. The browser calculates layout and paints the next frame.
INP is the total of all three. It observes interactions throughout the whole visit and reports a value close to the slowest one, ignoring rare outliers on pages with many interactions.
Scrolling and hovering do not count. Clicks, taps, and key presses do.
INP Thresholds
| Rating | INP |
|---|---|
| Good | 200 ms or less |
| Needs improvement | Between 200 and 500 ms |
| Poor | More than 500 ms |
Google assesses a page at the 75th percentile of visits, which means three quarters of visits should meet the threshold. Mobile and desktop are assessed separately.
INP vs FID
First Input Delay measured only the first interaction and only the input delay part. A page could score well on FID and still feel sluggish every time a menu opened.
INP covers every interaction during the visit and the full time until the screen updates, which matches how responsiveness actually feels.
What a Poor INP Feels Like
- You tap a button and nothing appears to happen, so you tap again.
- Typing in a search box lags behind your fingers.
- A menu opens a beat late.
- A filter takes a moment and the page then jumps.
The second tap is the important part. Slow responses cause double submissions and rage clicks, and visitors conclude the site is broken.
Common Causes
- Long JavaScript tasks. Any task that holds the main thread for more than about 50 milliseconds delays input.
- Heavy event handlers. Doing all the work synchronously inside the click handler.
- Large re-renders. A small state change that causes a big part of the interface to redraw.
- Big DOM trees. Thousands of elements make every layout calculation slower.
- Third-party scripts. Chat, ads, A/B testing, and tag managers competing for the main thread.
- Hydration. In server-rendered apps, the page looks ready before it can respond.
- Slow devices. A mid-range phone has a fraction of a laptop's processing power.
How to Find Slow Interactions
Lab tools cannot produce a true INP, because INP depends on what real people do. You need field data.
- Start with real-user data. Find the pages with the worst INP, by device.
- Reproduce on a slow profile. In your browser's performance panel, throttle the CPU and interact with the page.
- Look at the interaction's breakdown. Is it input delay, processing, or presentation?
- Watch sessions on the slow page. Repeated taps on one element usually mark the slow interaction.
DeepSync captures real-user LCP, CLS, and INP from actual visits, plus your slowest pages and resources, on Pro and above (performance docs). Because sessions are recorded too, you can go from a slow page to the recordings where people tapped twice.
Test on the device your customers use
A page that responds instantly on a development laptop can take several hundred milliseconds on a mid-range Android phone.
How to Improve INP
- Give feedback immediately. Show a pressed state or spinner first, then do the work.
- Break up long tasks. Yield to the browser between chunks of work.
- Defer non-urgent work until after the next paint.
- Reduce what re-renders. Update only the part of the interface that changed.
- Shrink the DOM. Virtualise long lists.
- Audit third-party scripts and remove or delay what you can.
- Debounce input handlers for search and filters.
- Avoid layout thrashing, which is reading and writing layout properties repeatedly in a loop.
Key Takeaways
- INP measures how quickly the page responds to clicks, taps, and keys.
- Good is 200 ms or less; poor is above 500 ms.
- It needs real-user data, split by device.
- Fix long tasks, heavy handlers, large re-renders, and third-party scripts.
Conclusion
INP is the Core Web Vital that most closely tracks whether a site feels broken. Find the slow interaction, give instant feedback, and move the heavy work out of the way.
Frequently Asked Questions
Related articles
Stay in the loop
Get the latest insights on product analytics and user behavior delivered to your inbox.



