Performance & Patterns
Performance is a rendering problem
Section titled “Performance is a rendering problem”React is fast by default. Almost every real performance problem comes down to one of two things: rendering too often (components re-render when nothing they show has changed) or rendering too much (a single render does expensive work). The fixes are structural — keep state low, stop re-render propagation where it does not matter, and only reach for memoization once a profiler shows you need it.
This module also covers the patterns that make components composable — because a well-composed component tree is usually a fast one.
What this module covers
Section titled “What this module covers”| Lesson | What you’ll learn |
|---|---|
| Rendering performance | Why components re-render, and how to render less |
| Memoization in practice | useMemo / useCallback / React.memo — and the compiler |
| Composition patterns | Compound components, render props, controlled vs uncontrolled |
| Refs, portals & escape hatches | When to step outside the declarative model |
The one rule of optimization
Section titled “The one rule of optimization”flowchart LR slow["Something feels slow"] --> profile["Profile it (React DevTools)"] profile --> find["Find the actual cause (too many renders? too much work?)"] find --> fix["Fix that specific cause"] fix -. avoid .-> guess["Sprinkling memo everywhere by guessing"]
The most common mistake is memoizing by reflex — wrapping everything in useMemo/useCallback before knowing whether it helps. Memoization has its own cost (memory, comparison, complexity), and the React Compiler now automates most of it. Profile first, fix the real cause, and let the compiler handle the rest.