Interaction to Next Paint: The Metric That Exposes Bad JavaScript

Of the Core Web Vitals, Interaction to Next Paint is the one teams find hardest to move. That difficulty is the point — it measures something the earlier responsiveness metric largely missed, and it is closer to what users actually experience as sluggishness.

What It Measures

INP looks at the delay between a user interacting — tap, click, key press — and the browser painting a visual response. It considers interactions across the entire page visit, not just the first one, and reports close to the worst case rather than the average.

That framing matters. A page can load quickly and still feel broken if the third tap on a filter control takes half a second to register. Users remember the worst interaction, and INP is built to catch it.

The Usual Cause Is the Main Thread

Browsers run JavaScript on a single main thread that also handles rendering. When a long task occupies that thread, input events queue behind it. The interface has not crashed — it simply cannot respond until the task finishes.

Common culprits: oversized event handlers doing synchronous work, large re-renders triggered by minor state changes, expensive layout recalculation, hydration of components far larger than they need to be, and third-party scripts executing whenever they please.

Practical Remedies

Break long tasks into smaller chunks and yield to the browser between them. Move heavy computation into web workers, off the main thread entirely. Give immediate visual acknowledgement — a pressed state, a spinner — before the expensive work begins, so the response is instant even when the result is not.

On the framework side, reduce hydration scope. Ship less JavaScript for content that does not need interactivity. Server components and islands architectures exist largely to address this class of problem.

Third-Party Scripts Deserve Scrutiny

Tag managers, chat widgets, analytics, session recorders and personalisation tools each add main-thread work you do not control. They are frequently the dominant contributor to poor INP and are rarely audited after installation. Load them late, load them conditionally, and periodically ask whether each one still earns its cost.

Measure Real Users, Not Just the Lab

Synthetic testing runs on fast hardware with a fresh cache and no extensions. Field data from real devices tells a different and more accurate story. Optimise against what users on mid-range phones actually experience.

INP rewards restraint. The most effective fix is usually not clever optimisation — it is shipping less code in the first place.