❯ Performance Optimization

Roughly 12% of a typical loop — and 12% of the mock exam here.

Memoization — and how it silently fails

memo skips re-rendering a component when its props are shallow-equal, compared with Object.is. The classic trap: a candidate wraps a component in memo, then passes an inline object or arrow function. Every render creates a fresh reference, the comparison fails, and the memo does nothing — while still charging for the comparison.

// memo defeated: both props are new references every render
<MemoizedRow style={{ padding: 8 }} onSelect={() => select(id)} />

The fix is useMemo for object and array props, useCallback for functions — but know the real cost-benefit. Every memoization hook adds a dependency comparison on every render plus retained memory, and it clutters the code. Per react.dev, useMemo earns its place only when the computation is measurably slow and its dependencies rarely change, or when the value feeds a memo-wrapped child or another hook’s dependency array. “Memoize everything” is the trap answer; “profile, then memoize proven hotspots” is the rule that resolves it.

The React Compiler changed the default answer

React Compiler 1.0 shipped stable in October 2025. It auto-applies the equivalent of memo, useMemo, and useCallback at build time — including intermediate values that manual memoization misses. It works best with React 19 and also supports 17 and 18. In a compiled codebase, hand-written memoization is mostly obsolete.

What it does not obsolete: architecture. The compiler cannot fix a slow algorithm, an oversized bundle, or state lifted too high. A strong 2026 answer names the compiler and its limits — colocating state, passing JSX as children, and keeping renders pure still matter.

Ship less, render less

Two levers that beat any memo:

• Code splitting — lazy(() => import('./Chart')) plus a Suspense boundary with a fallback loads a route or heavy widget on demand instead of in the main bundle. Split at routes first; that is where the payoff is largest.
• List virtualization — for long lists, render only the visible window (react-window, TanStack Virtual). A 10,000-row table becomes roughly 20 mounted rows. No memoization competes with not rendering.

Related trap: key={index} on a list that reorders or inserts. React matches children by key, so row state and memo caches stick to the wrong items and reconciliation degrades into churn. Keys must be stable identity, unique among siblings.

Measure first: Profiler and INP

The React DevTools Profiler records commits and shows a flame graph of what rendered, how long it took, and — with “record why each component rendered” enabled — which prop or state change caused it. React 19.2 also added Scheduler and Components tracks to Chrome DevTools performance profiles, so React’s priority lanes show up alongside browser work.

Connect it to Web Vitals: INP (Interaction to Next Paint) measures how long the page takes to paint after an interaction. A long synchronous render blocks that paint, so slow React renders are an INP problem. Marking non-urgent updates with startTransition or useDeferredValue keeps typing and clicks responsive while heavy renders proceed at lower priority.

Effect chains are a performance bug

A chain of useEffect hooks where each one sets state that triggers the next causes cascading render passes — three chained effects can mean three full extra renders per change. The react.dev rule: if a value can be computed from props or state, derive it during render (memoized if expensive) instead of mirroring it into state via an effect. Reserve effects for synchronizing with external systems, and use React 19.2’s useEffectEvent to keep incidental values from re-running an effect at all.