INP Is Now an Equal Ranking Signal and 'Good' LCP Dropped to 2.0s: A React Engineer's Fix List

The LCP change is the quieter trap. A page sitting at 2.3s was "Good" on 17 March and "Needs improvement" on 18 March without a single line of code changing. Pull your field data before you assume you are still passing.

How is INP different from FID, and why does my React app fail it?

INP measures the full latency of an interaction from input to the next paint, across the entire visit, not just the first one. FID only measured input delay on the first interaction, so it forgave almost everything React does after a click.

INP captures three phases: input delay (the main thread is busy when you click), processing time (your event handlers and React re-renders), and presentation delay (the browser painting the result). React apps usually fail in the middle phase. A single click triggers a state update, which triggers a synchronous re-render of a large component tree, which blocks the main thread long enough to push you past 200ms.

The classic culprit is an expensive update fired on a high-frequency event. A search box that re-renders a 500-row list on every keystroke. A filter that recalculates a derived dataset inside render. A controlled form where every keypress walks a deep context provider. None of these showed in FID. All of them show in INP.

What are the React-specific INP fixes, in priority order?

Fix the main-thread work per interaction first: break long tasks, mark non-urgent updates with transitions, and stop re-rendering trees that do not need to change. These three account for most INP failures I see.

Start with useTransition and useDeferredValue. If a state update drives an expensive render, mark it non-urgent so React keeps the input responsive and renders the heavy part without blocking the paint.

import { useState, useTransition } from 'react';

function ProductSearch({ allProducts }) {
  const [query, setQuery] = useState('');
  const [results, setResults] = useState(allProducts);
  const [isPending, startTransition] = useTransition();

  function handleChange(e) {
    // Urgent: keep the input painting immediately.
    setQuery(e.target.value);
    // Non-urgent: the expensive filter render is deferred.
    startTransition(() => {
      setResults(allProducts.filter(p => p.name.includes(e.target.value)));
    });
  }

  return (
    <>
      <input value={query} onChange={handleChange} />
      <ResultList items={results} dimmed={isPending} />
    </>
  );
}

The input now repaints on the urgent update while the list render happens off the critical path. That difference is often the gap between 240ms and 90ms.

Next, break long tasks. Any task over 50ms on the main thread is a "long task" and blocks input. If a handler does heavy synchronous work, yield to the browser so it can paint queued interactions. The modern way is scheduler.yield() where supported, with a setTimeout fallback:

async function processBatch(items) {
  for (const chunk of chunkify(items, 50)) {
    doWork(chunk);
    // Yield so the browser can handle pending input and paint.
    if ('scheduler' in window && 'yield' in scheduler) {
      await scheduler.yield();
    } else {
      await new Promise(r => setTimeout(r, 0));
    }
  }
}

Third, stop the avoidable re-renders. Memoize the components and values that sit downstream of a frequent update. The React Compiler (stable as of React 19) auto-memoizes for you, which I will come back to, but if you are not on it yet, React.memo, useMemo, and stable callbacks on the hot path are still the move. Profile first with the React DevTools Profiler so you memoize the component that is actually expensive, not the one that looks expensive.

Does the React Compiler actually help INP?

Yes. The React Compiler automatically memoizes components and hook values at build time, which cuts the re-render work that drives INP processing time, without you hand-writing useMemo and useCallback everywhere. It is the single highest-leverage INP change for a large existing React codebase.

The reason it helps INP specifically: most React INP failures are wasted re-renders triggered by an interaction. The compiler skips re-rendering subtrees whose inputs did not change, so each click does less main-thread work. You enable it through the Babel plugin and let it run across your tree.

// babel.config.js
module.exports = {
  plugins: [
    ['babel-plugin-react-compiler', { /* defaults are fine to start */ }],
  ],
};

One honest caveat: the compiler is only as good as your code's adherence to the Rules of React. If components mutate props or read refs during render, the compiler bails out of optimizing them and you get nothing. Run the ESLint plugin, fix the violations it flags, and you will see the compiler actually engage. I treat "clean up Rules of React violations" and "turn on the compiler" as one task, not two.

If you are auditing a Next.js app, this overlaps with how crawlers see your JavaScript. A heavy client bundle hurts both INP and machine readability, which I dug into in why your Next.js SPA is invisible to AI crawlers ↗.

How do I hit the new 2.0s LCP bar with React?

Get the largest element rendered server-side and streamed early, and stop blocking it behind JavaScript. The 2.0s bar punishes any LCP image or hero text that waits for hydration before it paints.

Streaming SSR with React Server Components is the biggest lever here. With Suspense boundaries, the server flushes the above-the-fold content immediately and streams the slower parts after, so the LCP element is in the first chunk of HTML.

// app/page.jsx (Next.js App Router)
import { Suspense } from 'react';

export default function Page() {
  return (
    <>
      {/* LCP element: server-rendered, in the first flush, no JS wait. */}
      <Hero />
      <Suspense fallback={<FeedSkeleton />}>
        {/* Slow data streams in after, does not block LCP. */}
        <PersonalizedFeed />
      </Suspense>
    </>
  );
}

Then protect the LCP element directly. Set priority on the Next.js for your hero so it gets a fetchpriority="high" and is not lazy-loaded. Preconnect to the image CDN. Inline the critical font or use font-display: optional so the LCP text does not wait on a font swap.

import Image from 'next/image';

<Image src="/hero.webp" alt="..." width={1200} height={600} priority />

The pattern that breaks the 2.0s bar most often is a hero image discovered late because it is inside a client component that hydrates before it requests the image. Move the LCP element out of the client boundary and into the server tree.

What is a realistic third-party script budget?

Treat third-party JavaScript as a hard budget, not a wishlist: every analytics, chat, A/B, and tag-manager script competes for the same main thread that INP measures. My working rule is that third-party scripts should not own more than about 20% of main-thread time during the interaction window, and anything non-essential loads after first interaction.

Tag managers are the worst offenders because they pull in more scripts you never audited. Here is the budget I apply on a rescue: