# How to fix INP in Next.js and React (2026 playbook) *By Roberto Lazar, founder of Dock30 · Published 2026-06-10 · Updated 2026-07-25 · 7 min read* Client-hydrated React and Next.js sites fail INP at about three times the rate of static ones. The causes we see most in audits, and the fixes that work. To fix Interaction to Next Paint (INP) in a Next.js or React app, do three things: ship less JavaScript by keeping components on the server, move expensive renders off the critical path with `startTransition` or `useDeferredValue`, and load third-party scripts through `next/script` so they stop competing with your users for the main thread. INP is graded on field data at the 75th percentile, and a good score is **200 ms** or less. In our audits, the first two fixes alone are usually enough to get a failing app under that bar. First, some honesty about the numbers, because the scary version of this article has been written many times. Most of the web passes INP now. In the May 2026 CrUX dataset, **86.6%** of origins had a good INP, and the [Web Almanac 2025](https://almanac.httparchive.org/en/2025/performance) puts good INP at 77% of mobile origins and 97% on desktop. LCP is the vital most sites actually fail, sitting at 68.6% good per the [Core Web Vitals benchmarks for 2026](https://www.digitalapplied.com/blog/core-web-vitals-benchmarks-2026-pass-rate-reference). So why does INP still deserve its own playbook? Because those averages are carried by static and server-rendered sites. JS-heavy, client-hydrated React and Next.js apps fail INP at roughly **three times** the rate of server-rendered or static sites, a gap visible in the [framework benchmarks at webvitals.tools](https://webvitals.tools/benchmarks/). The average brochure site is fine. Your hydrated dashboard probably is not, and neither is an [ecommerce store where slow taps cost conversions](/services/websites-ecommerce). ## What INP measures and why React apps trip it INP replaced First Input Delay as a Core Web Vital on [March 12, 2024](https://web.dev/blog/inp-cwv-march-12). FID only measured the delay before your event handler started running. INP measures the full latency from a user interaction to the next frame the browser paints, and it reports the worst (or near-worst) interaction across the whole page visit. The grading bands: 200 ms or less at the 75th percentile is good, 200 to 500 ms needs improvement, over 500 ms is poor. Three things happen between a tap and the resulting paint, and each is a place React can stall: 1. Input delay. The main thread is busy, often hydrating or running a third-party script, so your handler cannot start yet. 2. Processing time. Your event handler runs, and so does the React render it triggers. 3. Presentation delay. The browser recalculates layout and paints the new frame. FID only saw the first slice. INP sees all three, which is exactly why frameworks that render in the browser felt the change hardest. A heavy synchronous render in step two, or a main thread clogged by hydration in step one, is what pushes most React apps over the line. ## The five INP killers we see in Next.js audits The same five causes show up in almost every failing app we look at, in roughly this order: 1. Hydration delay. Large client bundles hydrating on load block the first interactions a user attempts, sometimes for seconds on a mid-range phone. 2. `"use client"` contagion. One client component high in the tree turns the whole subtree into shipped, hydrated JavaScript, including the parts that never change. 3. Synchronous state updates. A single keystroke or click triggers a large blocking re-render, and the browser cannot paint anything until React finishes. 4. Oversized DOM. Thousands of nodes make every layout and paint slower, so even a cheap render produces a slow frame. 5. Third-party scripts. Analytics, chat widgets, and tag managers run on the same main thread as your handlers, and they do not queue politely. ## Fixes that actually move the number ### Mark non-urgent updates as transitions If an interaction kicks off an expensive render (filtering a big list, redrawing a chart), tell React the heavy part is not urgent so the browser can paint feedback first: ```tsx import { startTransition, useState } from "react"; function Filter({ items }: { items: Item[] }) { const [query, setQuery] = useState(""); function onChange(e: React.ChangeEvent) { const value = e.target.value; // Urgent: keep the input responsive setQuery(value); // Non-urgent: let the heavy list update yield to paint startTransition(() => { runExpensiveFilter(value); }); } return ; } ``` The input stays responsive because React treats the transition as interruptible work. When the expensive part is derived from a value rather than triggered by an event, `useDeferredValue` does the same job with less ceremony. These two APIs are still the primary interaction-latency levers in React 19. ### Default to Server Components The cheapest interaction is the one that needs no hydration at all. Keep components on the server by default and add `"use client"` only at the leaves that genuinely handle input. A product description, an article body, a pricing table: none of these should ship client JavaScript. Every kilobyte you keep on the server is main-thread time the browser gets back during the interactions that count. On the [Next.js and NestJS stack we deploy for clients](/blog/fullstack-nextjs-nestjs-postgres-railway), pushing client boundaries down to the leaves has repeatedly cut client bundles by half or more without removing a feature. ### Load third-party scripts on your terms Next.js 16 gives you three practical loading strategies through [`next/script`](https://nextjs.org/docs/app/api-reference/components/script): `beforeInteractive` for the rare script that truly must run first, `afterInteractive` (the default) for things like tag managers, and `lazyOnload` for everything that can wait until the browser is idle. ```tsx import Script from "next/script";