What INP measures, and how to improve it in React

Interaction to Next Paint (INP) is the Core Web Vital for responsiveness. It replaced First Input Delay, which only looked at the first interaction and only at the delay before work started. INP looks at the whole visit and at the whole interaction.

I get asked about it in interviews more than any other vital, because the fixes touch React internals, the event loop and measurement all at once. This is how I explain it.

What INP measures

An interaction is a click, a tap or a key press. Its latency is the time from the user input until the browser paints the next frame that reflects it. If you click a button and nothing visible changes for 400 ms, that interaction took about 400 ms.

The reported INP is roughly the worst interaction during the page visit. On pages with many interactions, a few outliers are ignored, so one freak slow click does not define the score. The point is that INP reflects what a user felt at its worst, not an average.

Try it yourself. Drag the slider to change how much work the click handler does, then click and read the measured time and its rating.

The three parts of an interaction

Every interaction has three phases. Input delay is the wait before your event handlers can start, usually because the main thread is busy with something else. Processing time is the time your handlers run. Presentation delay is the time from the end of the handlers until the browser has rendered and painted the next frame.

Knowing which phase is slow tells you which fix to reach for. A long input delay means something else is hogging the thread. Long processing means your handler or render is too heavy. Long presentation delay often means a big DOM or expensive layout.

Thresholds

The official bands are measured at the 75th percentile of page loads, split by mobile and desktop. That means 75 percent of your real visits need to be at or under the limit for the page to pass.

Why the main thread is the problem

JavaScript runs on one main thread, and the same thread handles input and painting. Any task that runs longer than 50 ms counts as a long task. While it runs, the browser cannot respond to a click or paint a new frame.

So a slow INP is almost always a long task in disguise. Either one was already running when the user clicked (input delay), or your own handler started one (processing time). The fixes below all do the same thing: make tasks shorter, or move them out of the way of the next paint.

Measure first

Do not guess. The web-vitals library gives you the same INP number Chrome reports, and its attribution build tells you which element and phase caused it. Send it to your analytics so you see real users, not just your fast laptop.

import { onINP } from "web-vitals/attribution";

onINP((metric) => {
  navigator.sendBeacon(
    "/analytics",
    JSON.stringify({
      name: metric.name,
      value: metric.value,
      rating: metric.rating,
      target: metric.attribution.interactionTarget,
    })
  );
});

Field data tells you what is slow for users. To find out why, reproduce it locally in the Chrome DevTools Performance panel. Record the interaction, find the long task, and read the flame chart to see which function ate the time. Throttle the CPU, because your machine is faster than most of your users' phones.

Keep urgent updates urgent in React

The classic case is a search box that filters a big list. Every keystroke updates state and re-renders thousands of rows, so typing stutters.

function Search({ items }: { items: string[] }) {
  const [query, setQuery] = useState("");
  const results = items.filter((i) =>
    i.toLowerCase().includes(query.toLowerCase())
  );

  return (
    <>
      <input value={query} onChange={(e) => setQuery(e.target.value)} />
      <List items={results} />
    </>
  );
}

useDeferredValue lets the input stay urgent while the list lags behind. React renders the input first, then re-renders the list in the background, and it can interrupt that render if the user types again.

function Search({ items }: { items: string[] }) {
  const [query, setQuery] = useState("");
  const deferred = useDeferredValue(query); 
  const results = useMemo(
    () => items.filter((i) => i.toLowerCase().includes(deferred.toLowerCase())),
    [items, deferred]
  );

  return (
    <>
      <input value={query} onChange={(e) => setQuery(e.target.value)} />
      <List items={results} />
    </>
  );
}

For the deferral to pay off, the slow child must be memoized (React.memo, or a useMemo on the result as above). Otherwise it re-renders with the parent on every keystroke anyway. Try the three modes below. Each row does a small amount of real busy-waiting, so the list is slow on purpose.

useTransition and startTransition do the same job from the other side. You wrap the state update itself and mark it as non-urgent. Use useTransition when you own the setter and want an isPending flag for a spinner. Use useDeferredValue when the value comes from props or a place you do not control.

function Tabs() {
  const [tab, setTab] = useState("home");
  const [isPending, startTransition] = useTransition();

  function select(next: string) {
    startTransition(() => setTab(next)); 
  }

  return <TabBar onSelect={select} pending={isPending} active={tab} />;
}

Break up long tasks and yield

Not all slow code is a React render. A click handler that loops over a large array, parses data or runs a heavy calculation blocks everything. Split the work into chunks and give the browser a chance to handle input and paint between them.

scheduler.yield() is the purpose-built tool, and it resumes your work with higher priority than a plain timer. It is available in Chromium-based browsers but not everywhere, so check support before relying on it and keep a fallback. A setTimeout of zero works as the fallback, with the downside that your continuation goes to the back of the queue.

export function yieldToMain(): Promise<void> {
  if ("scheduler" in globalThis && "yield" in (globalThis as any).scheduler) {
    return (globalThis as any).scheduler.yield();
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

export async function processInChunks<T>(items: T[], fn: (item: T) => void) {
  let last = performance.now();
  for (const item of items) {
    fn(item);
    if (performance.now() - last > 40) {
      await yieldToMain();
      last = performance.now();
    }
  }
}

Keep event handlers thin too. Do the minimum needed to show feedback, such as updating state, and push analytics calls, logging and other side work to after the paint. Batching, debouncing and avoiding layout reads inside loops all reduce processing time without any new APIs.

Move heavy work to a Web Worker

If the work is pure computation, such as sorting, parsing or crunching a large dataset, a worker takes it off the main thread entirely. Workers cannot touch the DOM, and data is copied between threads by default, so this pays off for CPU-heavy jobs, not small ones.

// sort.worker.ts
self.onmessage = (e: MessageEvent<number[]>) => {
  const sorted = [...e.data].sort((a, b) => a - b);
  self.postMessage(sorted);
};

// main thread
const worker = new Worker(new URL("./sort.worker.ts", import.meta.url));
worker.onmessage = (e: MessageEvent<number[]>) => setData(e.data);
worker.postMessage(bigArray);

Interview answer in 30 seconds

INP measures how long it takes from a user's click, tap or key press until the next frame is painted, and the page score is roughly the worst interaction, assessed at the 75th percentile. Good is 200 ms or less, and above 500 ms is poor. It has three parts: input delay, processing time and presentation delay. Slow INP usually comes from long tasks blocking the main thread. In React I mark non-urgent updates with startTransition or useDeferredValue, break long work into chunks that yield to the main thread, move heavy computation to a Web Worker, and keep event handlers small. I measure with web-vitals for field data and the DevTools Performance panel to find the cause.

Key takeaways

• INP is the latency from input to next paint, reported as roughly the worst interaction.
• Good is 200 ms or less, poor is above 500 ms, judged at the 75th percentile.
• Find the slow phase first: input delay, processing time or presentation delay.
• useTransition and useDeferredValue keep input responsive but do not speed up the work.
• Yield with scheduler.yield() where supported, with a setTimeout fallback.
• Use a Web Worker for pure CPU work, and measure in the field with onINP.