Interaction to Next Paint (INP) became a stable Core Web Vital in March 2024, replacing First Input Delay (FID). FID measured only the first interaction on a page; INP measures the worst interaction across the whole session — a much harsher and more honest metric. Most sites that had a green FID score discovered they have a yellow or red INP score.
Google ranks pages on the 75th-percentile INP across real users. The bar is < 200ms. If your p75 INP is 350ms, your page is "needs improvement" in Google's eyes — and CrUX data is fed into search ranking signals.
Step 1: find which page has the worst INP
Open your RUM dashboard (Nevision: /performance). Sort pages by p75 INP descending. Likely suspects: search results, dashboards, anything with virtualized lists or heavy filter interactions. Don't waste time optimizing the homepage if your /products page is the ranking-killer.
Step 2: identify the slow interaction
For the worst-INP page, look at which interaction type is slow: click, keyboard, or pointer. Open Chrome DevTools → Performance → record an interaction. The "Long Animation Frames" panel (new in Chrome 123+) shows you exactly which task on the main thread blocked rendering.
Common culprits: a synchronous React state update that triggers an expensive re-render, an analytics SDK doing heavy work on click, a heavy event listener (e.g. scroll handler that recalculates layout), a large hydration boundary firing on first interaction.
Step 3: defer non-critical work
The fix is almost always the same: get the work off the critical path. Use scheduler.yield() to break up long tasks. Wrap non-critical state updates in startTransition() (React 18+). Move analytics calls to requestIdleCallback or to after the next paint.
For React: a single setState that triggers a 200ms render is the most common INP killer. Profile with React DevTools, find the expensive component, memoize aggressively, or move the state to a child component so the rest of the tree doesn't re-render.
Step 4: verify in RUM, not Lighthouse
Lighthouse INP scores on your dev machine mean nothing. Real users on real devices on real networks are who Google measures. Watch your RUM p75 INP for the affected page over the next 7 days — it should improve as the new code rolls out and CrUX-equivalent samples accumulate.
Nevision sends a daily email when any page's p75 INP regresses past 200ms or worsens by >20% versus the previous baseline — turn that on so you catch regressions before Google does.