Interaction to Next Paint: why a fast page can still feel slow
A page can load fast and still lag when tapped. Interaction to Next Paint measures that lag. What causes it, the 200 millisecond target, and how to fix it.
The short answer
Interaction to Next Paint, INP, measures how long a visitor waits between doing something, a tap, a click, a key press, and seeing the screen respond. It looks at the whole visit and reports the slow end. Google’s target is 200 milliseconds or less for real visitors on mobile. Above that, the page feels sticky even if it loaded fast.
The cause is nearly always the same: the browser is busy running JavaScript when the visitor interacts, and it cannot respond until it is done.
What makes it slow
| Cause | What it looks like | Typical source |
|---|---|---|
| Heavy script on load | The first tap after the page appears does nothing for a moment | Frameworks that render the page with JavaScript, large bundles, analytics and tag managers initialising |
| Third-party tags | Random lag throughout the visit | Chat widgets, A/B testing tools, ad and tracking scripts |
| Expensive handlers | A specific menu, filter or form step feels slow every time | Handlers that rebuild large parts of the page, run heavy calculations or wait for network before showing anything |
| Layout thrash | Lag when opening or closing panels | Scripts that read and write layout repeatedly |
| Long tasks | Everything freezes for a moment | Any single piece of script running for more than about 50 milliseconds |
How to improve it
- Find the slow interactions. PageSpeed Insights field data reports INP; performance tools show which interactions and which scripts were responsible.
- Ship less JavaScript. Every kilobyte must be parsed and run before it can respond. Pages that are HTML with a few small interactive islands have far less to run.
- Defer what is not needed now. Analytics, chat and tag managers can load after the page is interactive, not before.
- Make handlers respond first, work second. Show the menu or the loading state immediately, then do the heavy work. The visitor sees a response within milliseconds.
- Break up long tasks. Split heavy work so the browser can handle input between the pieces.
- Audit third parties. Each one is a potential source of lag you do not control. Remove what does not earn its place.
Why architecture decides it
A page that arrives as finished HTML with no script has nothing occupying the main thread when the visitor taps. Small interactive islands add only the script they need, when they need it. That is why sites built that way rarely have an INP problem to fix. A page that must run a framework and render itself with JavaScript before anything works starts with a busy main thread by design, and tuning can only reduce the problem, not remove it.
What this means for you
If your Core Web Vitals report shows INP as poor or needs improvement on mobile, the site is doing too much JavaScript work while visitors try to use it. Remove and defer third-party scripts first, then look at the specific slow interactions. If the site renders itself with a framework, the durable fix is a structure that ships HTML and adds script only where it is needed.
Frequently asked questions
How is this different from the page loading slowly?
Loading speed is about how fast content appears. INP is about what happens after: the visitor taps a menu, a filter, a button, and how long until something visibly changes. A page can appear in one second and then take half a second to open its own menu. INP measures the second problem.
Why is it fine on my laptop and poor for visitors?
Your laptop runs JavaScript several times faster than a mid-range phone. Work that takes 50 milliseconds at your desk takes 300 on the device your visitors use. INP is measured from real visitors, so it reflects their phones, not your machine.
Which interactions count?
Taps, clicks and key presses. Scrolling and hovering do not. Google looks at the slowest interactions of a visit, with some allowance for outliers on long visits, so one slow menu on every page can fail the whole site.
Can this be fixed without a rebuild?
Often partly: remove or defer heavy third-party scripts, make menu and filter handlers do less, split long tasks. Sites built on frameworks that render everything with JavaScript have a structural floor that tuning cannot go below. Sites built as HTML with small interactive islands start well under the target.
Sources
- Google web.dev: Interaction to Next Paint (INP) (accessed 2026-09-11)
- Google web.dev: Optimize Interaction to Next Paint (accessed 2026-09-11)
- Chrome for Developers: Total Blocking Time (accessed 2026-09-14)