React Performance Optimization Techniques

'Just wrap it in useMemo' is the most common — and most commonly wrong — React performance advice. Memoization is one tool among several, and reaching for it without profiling first tends to add complexity without fixing the actual bottleneck. This is a priority-ordered guide to what actually moves the needle.

Profile first, always

Before touching any optimization, open React DevTools' Profiler tab, record an interaction, and look at what actually re-rendered and why. Intuition about React performance is wrong often enough that skipping this step wastes more time than it saves.

Reduce what re-renders before making renders faster

The highest-leverage optimization in most React apps is structural: state placed too high in the tree causes everything beneath it to re-render on every update, regardless of whether that state affects them.

// BAD: search input state lives in the parent, so the entire
// (potentially large) results list re-renders on every keystroke.
function SearchPage() {
  const [query, setQuery] = useState("");
  const results = useSearchResults(query);

  return (
    <div>
      <SearchInput value={query} onChange={setQuery} />
      <ExpensiveResultsList results={results} />
    </div>
  );
}

// GOOD: isolate the input's local state, and debounce before
// it ever propagates to the state that drives ExpensiveResultsList.
function SearchPage() {
  const [committedQuery, setCommittedQuery] = useState("");
  const results = useSearchResults(committedQuery);

  return (
    <div>
      <SearchInput onCommit={setCommittedQuery} debounceMs={250} />
      <ExpensiveResultsList results={results} />
    </div>
  );
}

// SearchInput owns its own keystroke-level state internally,
// so ExpensiveResultsList only re-renders once the debounce fires.

Memoization: a scalpel, not a habit

Code splitting: cheap wins at the route level

// Next.js App Router splits by route automatically.
// For heavy client-only components (charts, editors), split explicitly:
import dynamic from "next/dynamic";

const AnalyticsChart = dynamic(() => import("@/components/AnalyticsChart"), {
  ssr: false,
  loading: () => <ChartSkeleton />,
});

Route-level splitting is close to free in Next.js — you get it automatically. Component-level splitting is worth doing for genuinely heavy, conditionally-rendered components (rich text editors, charting libraries, PDF viewers), but splitting every component 'just in case' adds request waterfalls that can hurt more than help.

Long lists: virtualize instead of memoizing harder

When a list grows into the hundreds or thousands of rows, no amount of memoization fixes the fact that you're mounting that many DOM nodes. Virtualization (rendering only the rows currently in the viewport) is the correct tool, and it's a different technique from memoization entirely.

• @tanstack/react-virtual — lightweight, headless virtualization primitives.
• react-window — a smaller, more opinionated alternative for simple lists and grids.
• Consider server-side pagination first — sometimes you don't need 2,000 rows in the client at all.

The fastest component is the one that never rendered in the first place. — Priya Nair, Staff Frontend Engineer, NavikaTech

Conclusion

React performance work rewards a specific order of operations: profile, then reduce unnecessary re-renders structurally, then memoize the specific things that measurably need it, then split code and virtualize where scale demands it. Skipping straight to memoization without the earlier steps is the most common way teams add complexity without a corresponding speed-up.