Performance (memo/useMemo/useCallback)

When and why to optimize React renders - React.memo, useMemo, useCallback, and the golden rule: measure before optimizing.

What it is, in plain English: React re-renders are usually cheap, so most components need no optimization at all. When a specific component IS measurably slow (expensive calculations, large lists), three tools help: React.memo skips re-rendering a component if its props haven't changed. useMemo caches the result of an expensive calculation between renders. useCallback caches a function reference so it doesn't change on every render -- important when passing callbacks to memoized children.

Most components don't need optimization

The golden rule: measure first. React's default re-rendering is fast. Adding memo/useMemo/useCallback everywhere "just in case" adds complexity and can actually make things SLOWER (memoization itself has a cost). Only optimize a component after you've measured it's actually slow.

React.memo -- skip re-rendering if props are unchanged

// Without memo: ExpensiveChild re-renders every time Parent re-renders,
// even if 'data' never changed:
function ExpensiveChild({ data }) {
  console.log("Rendering...");   // logs every time Parent re-renders
  return <div>{data}</div>;
}

// With memo: only re-renders if 'data' actually changed:
const ExpensiveChild = React.memo(function ExpensiveChild({ data }) {
  console.log("Rendering...");   // only logs when 'data' actually changes
  return <div>{data}</div>;
});

function Parent() {
  const [unrelatedState, setUnrelatedState] = React.useState(0);
  return (
    <div>
      <button onClick={() => setUnrelatedState(s => s + 1)}>Click</button>
      <ExpensiveChild data="constant" />
      {/* memo() skips re-rendering ExpensiveChild — its props never change */}
    </div>
  );
}

useMemo -- cache an expensive calculation's result

function ProductList({ products }) {
  // Without useMemo: this runs on EVERY render, even unrelated ones:
  const sorted = products.slice().sort((a, b) => b.price - a.price);

  // With useMemo: only re-sorts when 'products' actually changes:
  const sortedMemo = React.useMemo(() => {
    return products.slice().sort((a, b) => b.price - a.price);
  }, [products]);

  return <ul>{sortedMemo.map(p => <li key={p.id}>{p.name}</li>)}</ul>;
}
// Use useMemo for calculations that are genuinely expensive --
// sorting/filtering large arrays, complex math. NOT for simple operations.

useCallback -- cache a function reference

function Parent() {
  // Without useCallback: a NEW function is created every render:
  const handleClick = () => console.log("clicked");

  // With useCallback: the SAME function reference, unless deps change:
  const handleClickMemo = React.useCallback(() => {
    console.log("clicked");
  }, []);  // never changes

  return <MemoizedChild onClick={handleClickMemo} />;
  // Why this matters: MemoizedChild is React.memo'd, but a new onClick
  // function every render would defeat that memo (new reference = "changed prop")
}

Try It Yourself (JSX)

// Performance tools -- React.memo, useMemo, useCallback
// Rule #1: measure first. Don't add these without a measured problem.

// React.memo -- skip re-rendering if props haven't changed
const ExpensiveCard = React.memo(function ExpensiveCard({ title, count }) {
  console.log("Rendering ExpensiveCard:", title);
  return <div>{title}: {count}</div>;
});

function Parent() {
  const [count, setCount] = React.useState(0);
  const [other, setOther] = React.useState(0);

return (
    <div>
      <button onClick={() => setCount(c => c + 1)}>Increment count ({count})</button>
      <button onClick={() => setOther(o => o + 1)}>Increment other ({other})</button>
      {/* ExpensiveCard only re-renders when 'title' or 'count' actually change,
          NOT when 'other' changes -- thanks to React.memo */}
      <ExpensiveCard title="Stats" count={count} />
    </div>
  );
}

// useMemo -- cache an expensive calculation
function ProductList({ products, searchTerm }) {
  const filtered = React.useMemo(() => {
    console.log("Filtering products...");
    return products.filter(p => p.name.toLowerCase().includes(searchTerm.toLowerCase()));
  }, [products, searchTerm]);  // only re-filter when these change

return (
    <ul>
      {filtered.map(p => <li key={p.id}>{p.name}</li>)}
    </ul>
  );
}

// useCallback -- cache a function reference
function SearchPage() {
  const [query, setQuery] = React.useState("");

// Without useCallback, this is a NEW function every render,
  // which would defeat React.memo on SearchInput below:
  const handleSearch = React.useCallback((value) => {
    console.log("Searching:", value);
  }, []);  // empty deps = same function reference forever

return <SearchInput onSearch={handleSearch} />;
}

const SearchInput = React.memo(function SearchInput({ onSearch }) {
  console.log("SearchInput rendered");
  return <input onChange={e => onSearch(e.target.value)} />;
});

function App() {
  return (
    <div>
      <Parent />
      <ProductList products={[{id:1,name:"Apple"},{id:2,name:"Banana"}]} searchTerm="" />
      <SearchPage />
    </div>
  );
}

When optimization actually matters

The referential equality problem

// React.memo compares props with Object.is() (basically ===).
// Objects, arrays, and functions are NEW references every render unless memoized:

function Parent() {
  // ✗ This object is a NEW reference every render, even if its CONTENTS are identical:
  const style = { color: "red" };
  return <MemoChild style={style} />;   // memo is USELESS here -- style always "changed"

  // ✓ Memoize it:
  const styleMemo = React.useMemo(() => ({ color: "red" }), []);
  return <MemoChild style={styleMemo} />;   // now memo actually works
}

const MemoChild = React.memo(function MemoChild({ style }) {
  console.log("MemoChild rendered");
  return <div style={style}>Text</div>;
});

Measuring before optimizing -- React DevTools Profiler

// Install React DevTools browser extension, open the "Profiler" tab:
// 1. Click record
// 2. Interact with your app
// 3. Stop recording
// 4. See a flame graph: which components rendered, how long each took,
//    and WHY each one re-rendered (props changed / state changed / parent re-rendered)

// This tells you EXACTLY where to focus optimization effort,
// instead of guessing and memoizing everything defensively.

List virtualization -- for genuinely large lists

// Rendering 10,000 DOM nodes is slow, regardless of memoization.
// Virtualization only renders the items currently visible in the viewport:
// npm install react-window
import { FixedSizeList } from "react-window";

function VirtualizedList({ items }) {
  return (
    <FixedSizeList height={400} itemCount={items.length} itemSize={35} width="100%">
      {({ index, style }) => (
        <div style={style}>{items[index].name}</div>
      )}
    </FixedSizeList>
  );
}
// Only ~15 DOM nodes exist at once (whatever fits the 400px viewport),
// no matter how many thousands of items are in the data.

React Compiler and the future of memoization

// React Compiler (React 19+, formerly "React Forget") automatically applies
// memoization at BUILD time -- analysing your code and inserting the equivalent
// of useMemo/useCallback/memo wherever beneficial, without you writing them manually.

// Code you write (no manual memoization):
function ProductList({ products, searchTerm }) {
  const filtered = products.filter(p => p.name.includes(searchTerm));
  return <ul>{filtered.map(p => <li key={p.id}>{p.name}</li>)}</ul>;
}

// The compiler analyses this and produces optimized output equivalent to
// manually wrapping the filter in useMemo and the component in memo --
// but you never had to write that code, and it can't go stale (a common
// bug with manual useMemo dependency arrays that don't list everything used).

// This doesn't mean memoization knowledge is obsolete -- understanding
// WHY re-renders happen and WHEN they matter is still essential for
// debugging performance issues and understanding what the compiler is doing.

Cost-benefit of manual memoization

Every useMemo/useCallback call has a real cost: extra memory to store the cached value, extra comparison work on every render to check if dependencies changed, and meaningfully more code complexity. For a cheap calculation (formatting a string, simple arithmetic), the memoization overhead can exceed the cost of just recalculating it. The React team's general guidance: profile first, optimize the components the Profiler actually flags as slow, and treat universal memoization as a code smell rather than a best practice.

Official Sources

The Codex links only to official documentation. No third-party tutorials.