Stop Wrapping Everything in React.memo

If you’ve worked on a React codebase of any size, you’ve seen it: components wrapped in React.memo like it’s some kind of performance insurance policy. Developers sprinkle it everywhere, hoping it will make their app faster. It rarely does what they think it does. Most of the time, it adds overhead instead of removing it.

Here’s the uncomfortable truth: React.memo only helps in specific, measurable situations. Everywhere else, it’s dead weight that makes your code harder to read and your bundle slightly larger. This guide walks through exactly how React.memo works, when it genuinely improves performance, when it actively hurts, and how to make the call in your own codebase.

What React.memo Actually Does

React.memo is a higher-order component. It takes your component and returns a new component that skips re-renders when its props haven’t changed. The comparison it uses by default is shallow equality — it checks each prop with Object.is().

That means it behaves identically to shouldComponentUpdate from class components, but for function components. When a parent re-renders, the memoized child checks: did any prop change? If no, skip the render. If yes, render as usual.

const ExpensiveList = React.memo(function List({ items, filter }) {
  // Only re-renders if items or filter change
  return items.filter(filter).map(item => 
{item.name}
);
});

The key word is props. React.memo does nothing for state changes, context changes, or forced re-renders inside the component itself. It only protects against re-renders caused by a parent component re-rendering and passing down the same props.

When React.memo Actually Helps

1. Pure Components with Expensive Renders

If a component does heavy computation — sorting large arrays, running canvas calculations, rendering complex SVGs — and its props rarely change, React.memo can save meaningful time. The cost of the shallow comparison is trivial compared to the cost of the render it avoids.

const DataGrid = React.memo(function DataGrid({ rows, columns, sortConfig }) {
  // Expensive: sorts 10,000 rows, computes column widths
  const sorted = useMemo(() => heavySort(rows, sortConfig), [rows, sortConfig]);
  return ...;
});

2. Components in Lists That Re-render Frequently

List items are a classic case. When a parent manages list state and one item changes, the parent re-renders, which re-renders every child. With React.memo, only the item whose props actually changed will re-render.

This matters most when your list has hundreds or thousands of items. A todo app with 20 items? Don’t bother. A data table with 500 rows? Worth considering.

3. Components with Stable Props That Sit Under Frequent Re-renders

Sometimes a component’s parent re-renders constantly — a timer, an animation frame, a live data feed — but a particular child underneath receives the same props every time. React.memo shields that child from the parent’s rendering churn.

When React.memo Hurts

Props That Change Every Render

This is the most common mistake. If you pass inline objects, arrays, or functions as props, they get a new reference on every parent render. React.memo does its shallow equality check, sees different references, and re-renders the child every single time. The memoization does nothing except add the cost of the comparison.

// This memo does NOTHING — onClick is a new function every render
const Button = React.memo(function Button({ label, onClick }) {
  return {label};
});

function Toolbar() {
  // New reference every render
  return  saveDoc()} />;
}

The fix: use useCallback for the function, or move the handler definition outside the render path. But don’t reach for useCallback reflexively either — only use it when passing callbacks to memoized children.

Lightweight Components

If a component renders a few DOM nodes and does minimal work, skipping its re-render saves almost nothing. The shallow comparison itself might cost more than the render it prevented. React’s reconciliation is fast for simple components. Trust it.

Components That Rely on Context

When a component consumes context, it re-renders when the context value changes regardless of React.memo on props. If you wrap a context-consuming component in React.memo, the memo only helps when the parent re-renders but context hasn’t changed. That’s a narrow window. Measure before you assume it matters.

The Shallow Comparison Trap

Shallow equality catches primitive prop changes cleanly: strings, numbers, booleans. It fails the moment you pass objects or arrays as props, because two objects with identical properties are not the same reference.

const item = { id: 1, name: 'Widget' };
const item2 = { id: 1, name: 'Widget' };
Object.is(item, item2); // false

This means if a parent creates a new object literal in its render function and passes it as a prop, React.memo will always see a “changed” prop and never skip. You need to keep object references stable — via useMemo, state, or module-level constants — or write a custom comparison function.

Custom Comparison Functions

React.memo accepts a second argument: a custom comparison function. It receives prevProps and nextProps, and returns true to skip the re-render or false to allow it. This is the opposite of shouldComponentUpdate, which returns true to render — a detail that has tripped up many developers.

const Chart = React.memo(
  function Chart({ data, options }) {
    return ;
  },
  (prev, next) => {
    return prev.data.id === next.data.id
      && prev.options.width === next.options.width;
  }
);

Custom comparisons are powerful but dangerous. If your comparison is wrong — if it returns true when props actually changed — your component shows stale data with no warning. Bugs like this are hard to trace. Use custom comparisons only when you have a clear reason and a test covering the behavior.

React.memo vs useMemo vs useCallback

These three tools serve different purposes, and mixing them up is a source of constant confusion.

• React.memo — memoizes a component, preventing re-renders when props are the same.
• useMemo — memoizes a value inside a component, preventing expensive recalculations.
• useCallback — memoizes a function reference, keeping it stable across renders so it doesn’t break React.memo on child components.

They work together, not as alternatives. useCallback keeps function props stable so React.memo on the child actually works. useMemo keeps object props stable for the same reason. React.memo uses those stable references to skip renders.

A Practical Decision Framework

Instead of memorizing rules, run through this checklist when you consider adding React.memo:

1. Is the component expensive to render? If it’s a few divs and a text node, don’t bother.
2. Does the parent re-render often with the same props for this child? If the parent barely re-renders, memoization on the child has no opportunity to help.
3. Are the props stable? Primitives and stable references work. Inline objects and functions defeat the purpose.
4. Did you measure? Use React DevTools Profiler. Look at the actual render times. If the component isn’t in your top render-cost offenders, optimizing it is premature.

The React documentation on memo is explicit about this: use it as a performance optimization, not as a default. The React team themselves advise reaching for it only when profiling shows a real problem.

FAQ

Does React.memo shallow-compare props, or does it do a deep comparison?

It does a shallow comparison by default, using Object.is() on each prop value. It does not deeply compare objects or arrays. If you need deep comparison logic, you must provide a custom comparison function as the second argument — but be cautious, as incorrect comparisons cause stale renders.

Should I wrap every component in React.memo just in case?

No. Adding React.memo everywhere adds comparison overhead to every render, makes code harder to read, and can mask real performance issues by making you think you’ve optimized when you haven’t. Use it only where profiling shows a measurable benefit.

What happens if I use React.memo with a custom comparison that returns true when props change?

Your component will not re-render even though it should. It will display stale data. This is a silent bug — React won’t warn you. Always test custom comparison functions thoroughly, and consider whether a custom comparison is truly necessary instead of keeping prop references stable.

Final Word

React.memo is a scalpel, not a shotgun. It solves a specific problem: unnecessary re-renders of components whose props haven’t changed. When your component is expensive, sits under a frequently re-rendering parent, and receives stable props, it’s the right tool. In every other case, it’s noise. Profile first. Measure the actual cost. Then decide. The best optimization is the one you can justify with data, not the one you added because it felt safe.