ESC

Type to search the knowledge base.

React Performance Checklist

A practical React performance checklist: measure first, fix data flow, then memo, virtualize, and split code.

intermediate3 min read
  • react
  • react-performance

Performance work without a checklist becomes random useMemo. Use this order — measure, structure, then micro-optimize.

1. Measure

  • React DevTools Profiler for component time.
  • Browser Performance panel for long tasks.
  • Network for JS weight and waterfalls.
  • Field metrics (INP, LCP) for real users.

No number, no “optimization.”

2. Fix structure before memo

  1. Colocate state — high-churn state should not live above expensive pure trees (state colocation).
  2. Composition — pass children so parents re-rendering do not recreate heavy subtrees unnecessarily.
  3. Split context — avoid mega-providers (context pitfalls).
  4. Keys — wrong keys remount and thrash (keys).
  5. Derived data — compute in render; do not effect-sync (derived state).

3. Concurrent scheduling

function FilterPage({ rows }) {
  const [text, setText] = useState('');
  const [query, setQuery] = useState('');
  const [isPending, startTransition] = useTransition();

  return (
    <>
      <input
        value={text}
        onChange={(e) => {
          const next = e.target.value;
          setText(next);
          startTransition(() => setQuery(next));
        }}
        aria-label="Filter"
      />
      {isPending && <span aria-live="polite">Updating…</span>}
      <HeavyList rows={rows} query={query} />
    </>
  );
}

Keep the input urgent; mark the list update as a transition so typing stays responsive.

4. Targeted memoization

  • memo on proven heavy pure children.
  • useMemo / useCallback when referential stability is required by memo/deps — not everywhere.

5. Lists and code size

  • Virtualize huge lists (virtualization).
  • Lazy-load heavy routes/widgets (React.lazy).
  • Prefer Server Components for non-interactive UI in RSC apps.

6. Effects and subscriptions

  • Abort fetches; unsubscribe listeners.
  • Do not setState in loops.
  • Prefer event handlers over effect chains.

Anti-checklist (do not)

  • Memo every component “for performance.”
  • flushSync in hot paths.
  • Deep compare everything with custom memo.
  • Optimize before a profile.

Interview out-loud

“I measure with the profiler, fix state ownership and context scope first, then use transitions for heavy updates, memo only where props are stable and cost is proven, and virtualize or code-split large surfaces. Structure beats decoration.”

Further reading

Edge cases worth rehearsing

Interviewers and production incidents cluster around the same edges: first render versus update, empty and loading states, Strict Mode double setup, concurrent interruptions, and what happens when identity (key, route params, user id) changes mid-edit. Walk one concrete user journey end-to-end — open, edit, navigate away, come back — and say which state survives.

Prefer fixing data flow and ownership before reaching for memoization or micro-optimizations. Prefer event handlers over effects when a user action is the trigger. Prefer deriving values during render over mirroring props into state. Prefer stable list keys from business ids. Measure with the profiler when performance is the claim.

When you cite an API, mention one failure mode: abort on unmount, serializable props across server/client boundaries, focus restoration for dialogs, or cache invalidation after a mutation. Specific beats generic every time.

Edge cases worth rehearsing

Interviewers and production incidents cluster around the same edges: first render versus update, empty and loading states, Strict Mode double setup, concurrent interruptions, and what happens when identity (key, route params, user id) changes mid-edit. Walk one concrete user journey end-to-end — open, edit, navigate away, come back — and say which state survives.

Prefer fixing data flow and ownership before reaching for memoization or micro-optimizations. Prefer event handlers over effects when a user action is the trigger. Prefer deriving values during render over mirroring props into state. Prefer stable list keys from business ids. Measure with the profiler when performance is the claim.

When you cite an API, mention one failure mode: abort on unmount, serializable props across server/client boundaries, focus restoration for dialogs, or cache invalidation after a mutation. Specific beats generic every time.

Related guides