Fixing Interaction to Next Paint (INP): Taming JavaScript for a Responsive Page

## The short answer

Interaction to Next Paint (INP) measures how quickly your page visibly responds when a visitor taps, clicks or types. To improve it, you reduce the amount of work the browser's main thread does *during* interactions: break up long JavaScript tasks, defer non-essential work, trim third-party scripts, and let the browser paint before running heavy logic. A good INP is 200 milliseconds or below at the 75th percentile of real users. The root cause of poor INP is almost always JavaScript blocking the main thread.

## Why INP is stricter than the metric it replaced

INP became a Core Web Vital in 2024, replacing First Input Delay (FID). FID only measured the delay before the browser *started* processing the first interaction — a forgiving metric that most sites passed easily. INP is far more demanding because it measures the *full* interaction latency, across *all* interactions in a visit, not just the first. It captures input delay, processing time, and the delay before the next frame is painted. In short, INP reflects what users actually feel across an entire session.

## Step 1: Find which interactions are slow

Use field data first. Tools that read the Chrome User Experience Report, plus DevTools' Performance panel, will show which interactions are slow — opening a menu, submitting a form, expanding an accordion. Reproduce the slow interaction locally and record a performance trace to see exactly what runs.

Look for:

- Long tasks (over 50ms) triggered by the interaction

- Event handlers doing expensive work synchronously

- Layout thrashing — reading and writing the DOM repeatedly

## Step 2: Break up long tasks

The single biggest lever is splitting long JavaScript tasks so the browser can respond between chunks. Techniques include:

- **Yielding to the main thread.** Use `await scheduler.yield()` where available, or break work across `setTimeout` or `requestIdleCallback` so the browser can paint.

- **Deferring non-urgent work.** When a user clicks, do the minimum to give visual feedback, then schedule the rest for after the next paint.

- **Debouncing and throttling** high-frequency events like scroll, input and resize.

The mental model: respond visibly first, compute later.

## Step 3: Reduce the amount of JavaScript

Less code means less main-thread work. Practical moves:

- **Code-split** so routes only load the JavaScript they need.

- **Audit third-party scripts.** Chat widgets, A/B testing tools, tag managers and analytics are frequent INP offenders. Load them with lower priority, or remove ones that do not earn their keep.

- **Trim heavy dependencies** where a lighter alternative exists.

## Step 4: Optimise rendering work

Even with lean JavaScript, the way you update the page matters:

- **Avoid large synchronous DOM updates** during an interaction. Update what is visible, then the rest.

- **Use CSS `content-visibility`** to skip rendering off-screen content.

- **Batch DOM reads and writes** to avoid forced reflows.

## Step 5: Mind hydration on framework sites

Client-rendered and partially hydrated applications often have poor INP early in the page lifecycle because the framework is still hydrating when the user first interacts. Strategies include progressive or selective hydration, prioritising interactive components above the fold, and reducing the size of the hydration payload. This is where many modern sites lose the most INP.

## A worked example of the wrong order

Consider a "Add to basket" button that, on click, recalculates the entire cart, fires three analytics events, and re-renders a recommendations carousel — all synchronously. The user sees nothing for 400ms. The fix is to show the "added" state immediately, then schedule the recalculation, analytics and carousel update after the next paint. Same work, dramatically better INP, because the visible response comes first.

## Validate against real users

As with all Core Web Vitals, lab numbers are for diagnosis and field numbers are what count. INP is particularly prone to differing between lab and field because real users perform many interactions on varied devices. Confirm improvements in the Chrome User Experience Report over the following weeks. Instrumenting INP properly across a real user base is non-trivial, which is one reason teams adopt purpose-built products — the enterprise-grade tooling neart.ai builds in this space exists to make that instrumentation reliable.

## Practical takeaway

INP is a JavaScript discipline. Find your slowest interactions in field data, then apply one rule above all others: give the user a visible response first, and defer the heavy work until after the next paint. Break up long tasks, cut third-party bloat, and re-check your numbers in real-user data before declaring the job done.