Core Web Vitals: Fixing INP in React, Next.js and Vue Applications

Interaction to Next Paint replaced First Input Delay and caught a lot of teams out. FID measured the delay before the browser started handling your first interaction, which was a forgiving metric. INP measures the full time from interaction to visible response, across the whole visit, and reports close to the worst case. Sites that comfortably passed FID routinely fail INP.

What is a good INP score?

Under 200 milliseconds is good, 200 to 500 needs improvement, and above 500 is poor. The score reflects roughly the worst interaction a user experiences during a visit, not an average, so one slow control on a busy page can fail the whole page.

Why JavaScript frameworks struggle

Three patterns cause most failures:

• Long tasks blocking the main thread. Any task over fifty milliseconds delays every interaction queued behind it. Hydration is often the worst offender, because it runs precisely when users first try to interact.
• Expensive state updates. A click that triggers a re-render of a large tree spends its budget on reconciliation before anything appears on screen.
• Work done synchronously in the handler. Filtering a long list, formatting dates or building derived data inside a click handler blocks the paint the user is waiting for.

The fixes that actually move the number

Give visual feedback before doing the work

The metric ends when the next paint happens, not when your logic finishes. Update the visible state first, yield to the browser, then run the expensive part. A control that shows a pressed state immediately scores far better than one that completes silently and repaints at the end.

Break up long tasks

Split heavy work into chunks and yield between them. Modern browsers expose a scheduler for this, and a simple yield in a loop is a reasonable fallback. The goal is never occupying the main thread for more than about fifty milliseconds at a stretch.

Reduce hydration cost

Hydrate less. Server components, islands and lazy hydration all attack the same problem: shipping and executing less JavaScript on load. In Next.js, keeping components server-side by default and marking only genuinely interactive leaves as client components is the single biggest lever.

Memoise the expensive parts

Stop re-computing derived data and re-rendering subtrees that did not change. This is ordinary framework hygiene and it shows up directly in INP.

Defer non-essential third parties

Analytics, chat widgets and tag managers compete for the same main thread. Load them after interaction becomes possible rather than during it.

Measure the right thing

Lab tools will not reproduce this reliably, because INP depends on what real users click and on their hardware. Use field data: Search Console''s Core Web Vitals report, the Chrome UX Report, and real user monitoring that records which element caused the worst interaction. That last detail is what turns a bad score into a fixable ticket.

Chasing lab numbers while field data stays poor is the most common way teams waste a quarter on this metric.

A free audit pulls your real Core Web Vitals from field data rather than a simulated run.