Memoization: referential equality is the contract

What each tool actually caches

Three tools, three different cached things, one shared mechanism. useMemo(fn, deps) runs fn during render and caches its return value; on later renders, if every dep matches the previous render by Object.is, it returns the cached value without calling fn. useCallback(fn, deps) caches the function object itself — it never calls fn — and is literally useMemo(() => fn, deps). It does not make the function faster, doesn’t cache results of calling it; it preserves the function’s identity across renders. React.memo(Component) wraps a component: when the parent re-renders, React compares the new props object to the previous one shallowly — Object.is on each prop — and skips re-rendering the wrapped component (and reuses its last output) if all props match.

Note what is not on this list: none of these prevent re-renders from the component’s own state changes or from context it consumes. React.memo only filters re-renders propagating from the parent. And useMemo’s cache is per component instance, holds exactly one entry (the last one), and React reserves the right to throw it away — it’s a performance hint, not a semantic guarantee, which is why memoized code must produce the same result as un-memoized code.

Referential equality is the contract — and how it gets broken

All three tools answer the same question: “is this the same as last time?” — and answer it with reference identity, not structural equality. That makes them composable and fast (a handful of pointer comparisons), and it makes them brittle in one specific way: anything rebuilt during render is new. Object literals, array literals, arrow functions, and — the one that surprises senior candidates — JSX children. <Row>{label}</Row> creates a new React element object every render; an element is just { type, props, ... }, so a memoized component receiving children gets a fresh children prop reference each time, and the shallow comparison fails. The Hook’s table is the canonical case:

const Row = memo(function Row({ item, style, onSelect }) {
  /* expensive subtree */
});

// ❌ memo defeated twice per row, every parent render:
rows.map((item) => (
  <Row
    key={item.id}
    item={item}
    style={{ height: rowHeight }}        // new object identity each render
    onSelect={() => select(item.id)}     // new function identity each render
  />
));

// ✅ stable references — memo can actually bail out:
const style = useMemo(() => ({ height: rowHeight }), [rowHeight]);
const onSelect = useCallback((id) => select(id), [select]);
rows.map((item) => (
  <Row key={item.id} item={item} style={style} onSelect={onSelect} />
));

This is why useCallback exists at all: not to optimize the function, but to keep a child’s React.memo (or another hook’s deps array) from seeing a new reference every render. The contract is transitive and fragile — one inline object prop anywhere in the chain, and every memo below it does comparison work for nothing. The failure is silent: no warning, no error, just a Profiler showing the “memoized” subtree re-rendering on every commit. Production story in one line: a team memoized a chart component and shipped it; six months later someone added margin={{ top: 8 }} to the call site and the chart silently went back to re-rendering 60 times a second, surviving two more quarters because nothing broke — it just burned CPU.

When memoization is a net loss

Memoization is never free. Every useMemo/useCallback costs: the deps array allocation each render, the per-element Object.is walk each render, the cache slot held in memory for the component’s lifetime, and on the first render it is strictly slower (cache write plus the work). React.memo costs a shallow props walk on every parent render. These costs are small — a deps comparison is tens of nanoseconds — but the benefit can be smaller, and then you’ve made the code slower and harder to read:

• The computation is cheaper than the comparison. useMemo(() => first + ' ' + last, [first, last]): a string concat is comparable to or cheaper than two Object.is checks plus an array allocation. The Hook’s 47-useMemo PR was mostly this — pure overhead with a perf label on it.
• The deps change every render anyway. Memoizing with a dep that is itself rebuilt per render (an inline object, an unstable function from a non-memoized parent) means a 0% cache hit rate: full memoization cost, zero avoided work. This is the worst case — it looks optimized.
• The skipped subtree is trivial. React.memo on a component that renders two spans saves microseconds per skip while paying the props walk on every parent render. Memoization pays when the avoided work is large: re-render of a subtree with hundreds of components (milliseconds), an O(n log n) sort over thousands of rows, a layout-thrashing chart redraw.

The decision procedure is empirical, not aesthetic. When you are tempted to sprinkle useMemo across a component, open the React DevTools Profiler first, record the slow interaction, and read which commits are slow and which components actually take the time. Memoize the proven-expensive thing and the reference chain feeding it — and verify in the Profiler that the bailout now happens. A memo you didn’t verify is a memo that is probably broken by an inline prop somewhere, like the Hook’s 3,000 rows.

Profiling before memoizing

A concrete workflow that survives code review. One: reproduce the jank and record it in the Profiler — flame chart, ranked chart, “why did this render?” enabled. Two: identify the expensive commit and the components dominating it; typical findings are a wide list re-rendering wholesale, or one component doing heavy compute in render. Three: fix the cause — often that’s restructuring (move state down so the keystroke doesn’t render the page shell; pass JSX as children so the static part is created once by the parent and keeps its identity) before it’s memoization. Four: where memoization is the answer, apply it as a chain — memo on the expensive child, useCallback/useMemo on every reference that child receives — because a chain with one unstable link is all cost, no benefit. Five: re-record and confirm the bailout. Numbers from the Hook’s dashboard after doing it in this order: keystroke commit 38ms → 4ms, achieved by deleting 40 of the 47 useMemo calls, memoizing the row props properly, and moving the filter input’s state out of the table’s parent.