# Performance Optimization
Course: [React](https://www.devtutorials.ai/learn/react) · Section: Application Quality
Source: https://www.devtutorials.ai/learn/react/quality/performance-optimization
> Why performance matters, how React renders, avoiding extra re-renders, memoization with React.memo, useMemo and useCallback, lazy loading, code splitting and best practices.
## Why Performance Matters
**Performance** means how fast your app feels. A fast app opens quickly, and reacts at once when the user clicks or types.
Speed matters because people leave slow apps. It matters most on cheap phones and slow networks, which many of your users may have.
There are two kinds of slowness:
- **Slow loading.** The app downloads too much code before it can show anything.
- **Slow updates.** The app does too much work each time something changes.
This lesson shows simple ways to fix both.
### Real-World Example
A bookshop's search page shows 500 books. Each key press in the search box rendered all 500 cards again, so typing felt slow.
The team wraps `BookCard` in `memo`, sorts the list with `useMemo`, and passes handlers made with `useCallback`. Now a key press renders only the cards that changed.
Most React apps are fast enough without any tricks. First make your code correct and clear. Optimize only when something feels slow, and measure before and after.
## React Rendering and Performance
To **render** means React calls your component function to get its TSX. Then React compares the new result with the old one, and changes only the parts of the real page that are different.
A component renders again when:
- its own **state** changes,
- its **parent** renders again, or
- a **context** it reads changes.
The second point surprises many beginners. When a parent renders, **all** its children render too, even if their props did not change.
Only Counter shows the count, but all three children render again.
Each component below prints a line every time it renders. Click the button and watch the console. `Header` and `BookList` render again, even though nothing in them changed.
);
}
`,
"main.tsx": `import { createRoot } from "react-dom/client";
createRoot(document.getElementById("root")!).render();
`,
}}
/>
## Avoiding Unnecessary Re-renders
A re-render is **unnecessary** when it gives the same result as before. A few renders do no harm. They become a problem when a component is big or slow, such as a list with thousands of rows.
Simple ways to avoid them, before any special tools:
- **Keep state low.** Put state in the smallest component that needs it. Then only that component re-renders.
- **Do not copy data into state** if you can work it out from props or other state.
- **Use stable keys** in lists (like `book.id`), so React can reuse rows.
Typing now re-renders only SearchBox, not the big list.
Below, the search text lives in `SearchBox`, not in `App`. Type in the box. Only `SearchBox` renders. `BookList` stays quiet.
The Alchemist
Atomic Habits
);
}
console.log("App rendered");
return (
);
}
`,
"main.tsx": `import { createRoot } from "react-dom/client";
createRoot(document.getElementById("root")!).render();
`,
}}
/>
## Memoization Techniques
### What is Memoization
**Memoization** means remembering a result so you do not work it out again. If the inputs are the same as last time, you reuse the old answer.
React gives you three tools for this:
- `React.memo` remembers a **component's output**. It skips a render when the props are the same.
- `useMemo` remembers a **value**, such as a filtered list.
- `useCallback` remembers a **function**, so it stays the same between renders.
### React.memo
Wrap a component in `memo` to skip renders when its props have not changed:
```tsx
const BookList = memo(function BookList({ books }: Props) { ... });
```
Before each render, React compares the old props with the new props. If every prop is the same, React reuses the last result.
Memo saves work only when the props really stay the same.
);
}
`,
"main.tsx": `import { createRoot } from "react-dom/client";
createRoot(document.getElementById("root")!).render();
`,
}}
/>
Click the button a few times. `App` renders each time, but `Header` renders only once, because its prop `shop` is always `"Book Corner"`.
There is a trap. React compares props with `===`. A new object or a new function is created on **every** render, so it is never `===` the old one. Then `memo` does nothing.
- `useMemo(() => value, [deps])` keeps the same object until a dependency changes.
- `useCallback(fn, [deps])` keeps the same function until a dependency changes.
In the lab below, `onSelect` is wrapped in `useCallback`. Remove `useCallback` and see `BookList` render on every click.
{books.map((b) => (
onSelect(b.id)}>{b.title}
))}
);
});
const [count, setCount] = useState(0);
const [maxPrice, setMaxPrice] = useState(400);
// same list until maxPrice changes
const cheapBooks = useMemo(() => allBooks.filter((b) => b.price <= maxPrice), [maxPrice]);
// same function on every render
const handleSelect = useCallback((id: number) => {
console.log("Selected book " + id);
}, []);
return (
{" "}
);
}
`,
"main.tsx": `import { createRoot } from "react-dom/client";
createRoot(document.getElementById("root")!).render();
`,
}}
/>
Do not wrap everything in `memo`, `useMemo` and `useCallback`. Each one has a small cost too. Use them for big or slow components, or when the console shows many wasted renders.
## Loading and Bundle Optimization
When you build a React app, the build tool joins all your code into one or more JavaScript files called **bundles**. The browser must download a bundle before it can show the page. A big bundle means a slow start.
### Lazy Loading Components
**Lazy loading** means loading a component only when it is needed, not at the start. React gives you `lazy` and `Suspense` for this:
```tsx
const Reviews = lazy(() => import("./Reviews"));
```
- `import("./Reviews")` (with brackets) loads the file later, when the code runs. The file must have a `default` export.
- `lazy(...)` turns that into a component you can use like any other.
- `` shows the fallback while the component is still loading.
);
}
`,
"slowImport.ts": `export function slowImport(load: () => Promise): Promise {
// pretend the network is slow: wait 1 second, then load
return new Promise((r) => setTimeout(r, 1000)).then(load);
}
`,
"main.tsx": `import { createRoot } from "react-dom/client";
createRoot(document.getElementById("root")!).render();
`,
}}
/>
The playground loads files at once, so `slowImport.ts` waits one second to act like a slow network. In a real app, you write `lazy(() => import("./Reviews"))` and the network gives you the wait.
### Code Splitting
**Code splitting** means breaking the app's code into several smaller bundles. Each `import()` with brackets tells the build tool (like Vite): "put this file in its own bundle". So `lazy` is how you split code in React.
The user sees the page sooner, because the first file is smaller.
The most common place to split is by **page**. Each route gets its own bundle, and a user downloads a page only when they visit it.
```tsx
const AdminPage = lazy(() => import("./pages/AdminPage"));
Loading...}>
} />
```
## Component Splitting Strategies
How you split components also affects speed. Some simple rules:
- **Split by job.** A component that does one thing is easier to memo and to reuse.
- **Separate fast parts from slow parts.** Put a quickly changing input in its own small component, away from a big list.
- **Pass children.** A wrapper that takes `children` does not re-render them when its own state changes, because the children were made by the parent.
- **Lazy-load rare parts.** Dialogs, charts and admin pages that few users open can load later.
The lab below uses the `children` pattern. `ColorBox` has its own state, but `BigList`, passed as children, does not re-render when the colour changes.
{children}
);
}
function BigList() {
console.log("BigList rendered");
return (
The Alchemist
Wings of Fire
Atomic Habits
);
}
return (
);
}
`,
"main.tsx": `import { createRoot } from "react-dom/client";
createRoot(document.getElementById("root")!).render();
`,
}}
/>
## Performance Optimization Best Practices
- **Measure first.** Use the **Profiler** tab in React Developer Tools to see which components render and how long they take.
- **Build for production** to test speed. `npm run dev` adds extra checks and is slower than `npm run build`.
- **Keep state close** to where it is used.
- **Give list items stable keys**, like an id, not the array index.
- **Memoize only slow parts** with `memo`, `useMemo` and `useCallback`.
- **Lazy-load pages and rare parts** so the first bundle is small.
- **Show long lists in pages**, or only the rows on screen, instead of thousands at once.
- **Optimize images**: use the right size and a modern format.
Easy Way to Remember: measure, keep state low, memo the slow parts, lazy-load the rest.
## Common mistakes
| Mistake | What you see | Fix |
|---|---|---|
| Wrapping every component in `memo` | More code, no speed gain | Memo only big or slow components |
| Passing a new object or arrow function to a memo component | It still renders every time | Use `useMemo` or `useCallback` |
| Missing items in a `useMemo` dependency list | Old values show on screen | List every value used inside |
| Keeping input state at the top of the app | Typing feels slow in big pages | Move the state into the input's component |
| Using `lazy` without `Suspense` | An error when the component loads | Wrap it in `` |
| Lazy-loading a file with only named exports | An error: no default export | Add `export default` to the component |
| Testing speed with `npm run dev` | The app looks slower than it is | Test a production build |
## Check Yourself
## Exercises
## What to Remember
- A component renders when its state, its parent or its context changes. Keep state low to keep renders small.
- `memo` skips renders when props are the same. `useMemo` and `useCallback` keep objects and functions the same.
- `lazy` + `Suspense` load parts of the app later. This is code splitting, and it makes the first load faster. Measure before you optimize.
Next: Capstone - Task Management