Google replaced First Input Delay with Interaction to Next Paint as a Core Web Vital in March 2024. FID measured one thing: the delay before your first user input was processed. INP measures every interaction across the entire page visit and reports the worst one. The change broke most React apps quietly. Many sites that passed Core Web Vitals comfortably under FID dropped into the failing tier within weeks of the switch.
The threshold that matters: 200 milliseconds at the 75th percentile. If three quarters of your users experience an interaction faster than 200ms, you pass. If not, your Core Web Vitals report turns red and your rankings start sliding. Most React apps we audit in 2026 score between 250 and 450ms before optimization. Here is why and what to do about it.
Why React apps fail INP so consistently
FID had a generous failure mode for SPAs. The browser tracked the first input. If hydration finished before the user clicked, FID was effectively zero. Users who waited a beat before interacting got a passing measurement even on apps with terrible runtime performance.
INP closes that escape hatch. Every click, every input, every keystroke is measured. The slowest one across the page visit becomes your reportable score. React apps now show their real cost: the dropdown that re-renders 200 components, the form input that runs validation against the entire form on every keystroke, the dashboard widget that recomputes a derived selector every time state changes anywhere in the tree.
The three patterns that cause most failures
Across the audits we have run on React apps in the past year, three patterns account for the majority of INP failures.
- Synchronous hydration on heavy pages. When the entire page hydrates in one synchronous pass, every click that lands during hydration blocks until hydration completes. On large dashboards this can mean 600-800ms of input latency for unlucky users.
- Uncontrolled re-renders from context. A React Context that holds the entire app state re-renders every consumer on every change. Click a checkbox, recompute the cart total, update the badge, re-render the navbar, repaint the layout. The interaction looks instant in dev but compounds under load.
- Validation on every keystroke. Form libraries that run the whole validation schema on every input change cost 20-40ms per keystroke even on a fast machine. At 75th percentile on a mid-range Android phone the same code runs at 80-150ms per keystroke.
Fix 1 - Defer hydration with React Server Components or selective hydration
If your framework supports React Server Components (Next.js App Router, Remix's recent versions, Waku), use them for the parts of the page that do not need interactivity. The components ship as pre-rendered HTML and never hydrate. Your hydration cost drops by whatever percentage of the page does not need event handlers.
If you are still on Pages Router or a non-RSC framework, use selective hydration through React.lazy and Suspense boundaries. Wrap the heavy interactive widgets so they hydrate only when they enter the viewport or when the user starts interacting near them. The first-paint hydration tree shrinks, and INP for the first interaction drops by 100-200ms on typical layouts.
Fix 2 - Slice context and use selectors
The fix for context-driven re-renders is structural. Split the single big context into many small ones, or replace context with a state library that supports selectors (Zustand, Jotai, Redux Toolkit with reselect). The principle is the same: components should subscribe only to the slice of state they actually use.
If you cannot refactor the context shape, wrap the consumer with React.memo and pass only the specific values it needs as props. The optimization is fragile (it depends on referential equality) but it is a quick win when the right structural fix is weeks away.
Fix 3 - Move work out of the interaction path
Heavy work that does not need to block the user response should run in useTransition or in a Web Worker.
- useTransition for in-React work. Wrap state updates that drive expensive renders in
startTransition. The browser paints the urgent update first and processes the transition during idle time. INP for the urgent click drops dramatically. - Web Workers for parsing and computation. JSON parsing of large payloads, search index construction, image manipulation, encryption. Move them to a worker with Comlink and your main thread stays responsive even while the work runs.
- requestIdleCallback for analytics and tracking. Most analytics SDKs run their queue flush on every event. Wrap them in
requestIdleCallbackwith a long timeout and your INP improves on every page that fires events during interaction.
INP is the metric that exposes how an app feels in real use. Lab tests pass while users complain. The fix is almost always architectural rather than a single optimization.
Debugging INP in production
You cannot fix what you cannot measure. Three tools we install on every site we ship that needs to track INP in production.
Web Vitals JS library, sending real-user metrics to your analytics. Set it up with the onINP callback and tag each measurement with the user agent and device class. The aggregated data tells you which devices are failing, not just whether you are failing on average. Chrome DevTools Performance panel for local debugging, with the new Interactions track that highlights the slowest interactions across a session. PageSpeed Insights with field data, which surfaces the actual 75th percentile from real users hitting your site over the past 28 days.
What to ship this week
The action that pays back fastest is measuring before fixing. Add Web Vitals tracking, let it run for 7 days, then look at which interactions are slow. Most teams discover that one or two specific components account for the majority of bad measurements. Fix those first. The architectural rewrites can come later.
If your SEO performance is sliding and you have not audited Core Web Vitals since FID was retired, that is the single most likely cause. We run technical SEO audits that include INP debugging across the slowest 10 pages on the site, with concrete patches the dev team can ship rather than vague recommendations.
