1. 📖 Introduction

React is fast by default, but as applications grow — more components, deeper trees, larger lists — performance problems inevitably creep in. This tutorial covers the full toolkit for diagnosing and fixing them: rendering optimization, memoization, code splitting, list virtualization, and profiling, along with common pitfalls to avoid.

2. 🔍 Understanding React Performance

React's performance model centers on the render phase (computing what the UI should look like) and the commit phase (applying those changes to the real DOM). Most performance problems come from rendering too often or rendering too much at once.

3. 🚧 Performance Bottlenecks

Common sources of slowness in React apps include:

4. 🎯 Rendering Optimization

The single biggest lever for React performance is reducing how often, and how much, gets re-rendered. This involves both preventing unnecessary re-renders and making necessary ones cheaper.

5. 🔄 Re-rendering

A component re-renders whenever its state changes, its props change, or its parent re-renders — even if the new props are identical in value. Understanding this cascade is the foundation of all optimization work.

6. 🛡️ Preventing Unnecessary Re-renders

React provides three core tools to prevent wasted re-renders: React.memo for components, useMemo for computed values, and useCallback for function references. Each is covered in detail below.

7. 🧠 React.memo

React.memo wraps a component so it only re-renders when its props actually change (via a shallow comparison), skipping re-renders triggered purely by a parent update.

const ProductCard = React.memo(function ProductCard({ product }) {
  console.log("Rendering", product.name);
  return <div>{product.name} - {product.price{"}"}</div>;
});

8. 🧮 useMemo

useMemo caches the result of an expensive calculation, recomputing it only when its dependencies change.

function ProductList({ products, filterText }) {
  const filtered = useMemo(
    () => products.filter((p) => p.name.includes(filterText)),
    [products, filterText]
  );

  return <ul>{filtered.map((p) => <li key={p.id}>{p.name}</li>)}</ul>;
}

9. 🔗 useCallback

useCallback caches a function reference across renders, which matters most when that function is passed as a prop to a React.memo-wrapped child.

function ParentComponent() {
  const [count, setCount] = useState(0);

  const handleClick = useCallback(() => {
    console.log("Clicked!");
  }, []);

  return <MemoizedButton onClick={handleClick} />;
}

10. 💤 Lazy Loading

Lazy loading defers downloading and executing a component's code until it's actually needed — for example, a modal or settings panel the user might never open.

11. 🦥 React.lazy

React.lazy wraps a dynamic import() call, turning a component into one that loads its code on demand.

const SettingsPanel = React.lazy(() => import("./SettingsPanel"));

12. ⏸️ Suspense

<Suspense> displays a fallback UI while a lazy-loaded component's code is still downloading.

function App() {
  return (
    <Suspense fallback={<Spinner />}>
      <SettingsPanel />
    </Suspense>
  );
}

13. ✂️ Code Splitting

Code splitting breaks a single large JS bundle into smaller chunks, loaded only when needed — most commonly split by route or by heavy, rarely-used features.

const Dashboard = React.lazy(() => import("./pages/Dashboard"));
const Settings = React.lazy(() => import("./pages/Settings"));

<Routes>
  <Route path="/dashboard" element={<Suspense fallback={<Spinner />}><Dashboard /></Suspense>} />
  <Route path="/settings" element={<Suspense fallback={<Spinner />}><Settings /></Suspense>} />
</Routes>

14. 📦 Dynamic Imports

Beyond React.lazy, plain dynamic import() can defer loading non-component code too — like a heavy charting library only needed after a button click.

async function exportToPdf(data) {
  const { generatePdf } = await import("./pdfGenerator");
  return generatePdf(data);
}

15. 🧩 Component Splitting

Breaking a large component into smaller ones isn't just for readability — it also isolates re-renders. A state update in a small subcomponent no longer forces the entire parent tree to re-render.

// Before: one state change re-renders the whole page
function Page() {
  const [query, setQuery] = useState("");
  return (
    <div>
      <SearchInput query={query} onChange={setQuery} />
      <ExpensiveChart /> {/* re-renders on every keystroke, unnecessarily */}
    </div>
  );
}

// After: isolate the frequently-changing piece
function Page() {
  return (
    <div>
      <SearchBox />
      <ExpensiveChart />
    </div>
  );
}

16. 🖼️ Image Optimization

Images are often the heaviest assets on a page. Use appropriately sized images, modern formats (WebP, AVIF), and the native loading="lazy" attribute to defer offscreen images.

<img src="/hero.webp" alt="Product hero" loading="lazy" width={800} height={400} />

17. 📜 List Virtualization

Virtualization renders only the visible rows of a long list, plus a small buffer — instead of mounting thousands of DOM nodes at once.

import { FixedSizeList } from "react-window";

function ProductList({ products }) {
  const Row = ({ index, style }) => (
    <div style={style}>{products[index].name}</div>
  );

  return (
    <FixedSizeList height={600} itemCount={products.length} itemSize={50} width="100%">
      {Row}
    </FixedSizeList>
  );
}

18. 🪟 Windowing

"Windowing" is another name for the same technique as virtualization — only a small window of rows exists in the DOM at any time, with the rest tracked purely in memory. Libraries like react-window and react-virtualized implement this pattern.

19. ⏱️ Debouncing

Debouncing delays running a function until the user has stopped triggering it for a set period — ideal for search-as-you-type inputs that shouldn't fire a request on every keystroke.

function useDebouncedValue(value, delay) {
  const [debounced, setDebounced] = useState(value);

  useEffect(() => {
    const timeout = setTimeout(() => setDebounced(value), delay);
    return () => clearTimeout(timeout);
  }, [value, delay]);

  return debounced;
}

20. 🚦 Throttling

Throttling limits a function to running at most once per interval, regardless of how many times it's triggered — well-suited to high-frequency events like scroll or resize.

function throttle(fn, limit) {
  let waiting = false;
  return (...args) => {
    if (!waiting) {
      fn(...args);
      waiting = true;
      setTimeout(() => (waiting = false), limit);
    }
  };
}

21. 🗃️ Memoization Strategies

Choosing what to memoize is as important as knowing how. A good rule of thumb: memoize expensive computations and stable references passed to memo-wrapped children — not everything, everywhere.

22. 🗂️ State Optimization

Keeping state as local as possible — close to where it's used — limits how much of the tree re-renders when it changes. Lifting state up unnecessarily is a common source of avoidable re-renders.

// Better: dropdown's open/closed state stays local
function Dropdown() {
  const [isOpen, setIsOpen] = useState(false);
  // only this small component re-renders on toggle
}

23. 🌐 Context Optimization

Every component consuming a Context re-renders whenever any part of that context's value changes — even if the consumer only cares about one field. Split large contexts into smaller, focused ones to limit this blast radius.

// Instead of one large AppContext with { user, theme, cart }...
const UserContext = createContext(null);
const ThemeContext = createContext(null);
const CartContext = createContext(null);

// Components only re-render when the specific context they use changes

24. 📦 Bundle Size Optimization

A smaller JS bundle means faster downloads and faster parsing, directly improving initial load time. Key techniques: code splitting (Section 13), tree shaking (Section 25), and auditing dependencies for lighter alternatives.

25. 🌳 Tree Shaking

Tree shaking is a build-tool optimization that removes unused exports from the final bundle. It works best with ESM import/export syntax, since bundlers can statically analyze what's actually used.

// Good: only imports what's used, tree-shakeable
import { debounce } from "lodash-es";

// Avoid: imports the entire library
import _ from "lodash";

26. 🏗️ Production Builds

Always measure performance using a production build, never the development server — React's development mode includes extra warnings and checks that significantly slow down rendering.

npm run build
npm run preview

27. 📊 React Profiler

The React DevTools Profiler records how long each component takes to render and why it re-rendered, making it the primary tool for diagnosing real bottlenecks rather than guessing.

28. 🔬 Profiling Components

React also exposes a <Profiler> component for programmatic measurement, useful for automated performance regression tracking.

import { Profiler } from "react";

function onRender(id, phase, actualDuration) {
  console.log(`${id} (${phase}) took ${actualDuration}ms`);
}

<Profiler id="ProductList" onRender={onRender}>
  <ProductList products={products} />
</Profiler>

29. 📈 Performance Monitoring

Beyond local profiling, production monitoring tools (like RUM services or Web Vitals reporting) track real-world metrics — Largest Contentful Paint, Interaction to Next Paint, and similar — across your actual user base.

30. 🧠 Memory Optimization

Beyond render speed, React apps can suffer from memory growth over time — often from leaked subscriptions, timers, or event listeners that never get cleaned up.

31. 🚰 Avoiding Memory Leaks

Always clean up subscriptions, timers, and listeners in a useEffect cleanup function, or they'll keep running — and holding references — long after a component unmounts.

useEffect(() => {
  const handleResize = () => console.log(window.innerWidth);
  window.addEventListener("resize", handleResize);

  return () => window.removeEventListener("resize", handleResize);
}, []);

32. 🛠️ Optimizing Effects

Keep useEffect dependency arrays accurate and minimal. Effects that run more often than necessary — or that omit needed dependencies — are a frequent, subtle source of wasted work and bugs.

33. 🖱️ Optimizing Event Handlers

For frequent events like onScroll or onMouseMove, combine throttling/debouncing (Sections 19–20) with useCallback to avoid both excessive handler invocations and unnecessary child re-renders.

34. 📋 Optimizing Lists

Beyond virtualization, always give list items a stable, unique key — ideally an ID, never an array index for lists that reorder — so React can correctly match and reuse existing DOM nodes.

{products.map((product) => (
  <ProductCard key={product.id} product={product} />
))}

35. 📝 Optimizing Forms

Large, highly controlled forms can re-render the entire form on every keystroke. Splitting fields into isolated subcomponents, or using an uncontrolled approach via a library like React Hook Form, keeps typing responsive even in big forms.

36. 🚫 Performance Anti-Patterns

// Bad: InnerComponent is redefined and remounted every render
function Parent() {
  function InnerComponent() { return <div>Hi</div>; }
  return <InnerComponent />;
}

// Good: define components outside the render function
function InnerComponent() { return <div>Hi</div>; }
function Parent() {
  return <InnerComponent />;
}

37. 🔷 TypeScript Considerations

TypeScript itself doesn't affect runtime performance, but strict typing on memoized values and callback signatures helps catch a common bug: accidentally passing a differently-shaped prop that defeats React.memo's comparison.

interface ProductCardProps {
  product: { id: string; name: string; price: number };
}

const ProductCard = React.memo(function ProductCard({ product }: ProductCardProps) {
  return <div>{product.name}</div>;
});

38. 🏆 Best Practices

39. ⚠️ Common Mistakes

40. 💬 Frequently Asked Questions

Should I wrap every component in React.memo?

No — React.memo adds a comparison cost on every render. Reserve it for components that render often with genuinely unchanged props, especially ones with expensive render logic.

How do I know if my app actually has a performance problem?

Use the React DevTools Profiler on a production build to look for components with unexpectedly long or frequent render times before assuming optimization is needed at all.

Is virtualization always necessary for long lists?

Not always — lists of a few dozen items are usually fine unmodified. Virtualization becomes valuable once lists reach hundreds or thousands of rows.

41. 📌 Summary