React Performance — 3-Second Freeze from No Memoisation

React's declarative model is a gift — you describe what the UI should look like and React figures out how to get there. But that abstraction has a cost. In a large production app with hundreds of components, deeply nested state, and real-time data flowing in from WebSockets, React can easily end up doing tens of thousands of unnecessary renders per second. Users notice this as janky animations, sluggish inputs and frames dropping below 60fps. That's when 'React is fast enough' stops being true.

The root cause is almost always the same: developers treat re-renders as free. They're not. Every re-render means React has to call your component function, build a new virtual DOM tree, diff it against the previous one (reconciliation), and then commit any changes to the real DOM. Most of the time, the diff shows nothing changed — yet you still paid the cost of the function call and the tree construction. The optimisation techniques in this article all share a single goal: give React the information it needs to skip that work entirely.

By the end of this article you'll understand exactly how the React reconciler decides what to re-render and why, when to reach for React.memo, useMemo and useCallback (and critically, when NOT to), how to use code splitting and virtualisation to handle scale, and the production gotchas that bite even experienced engineers. Every example is pulled from patterns we've seen in real codebases.

How the React reconciler actually decides what to re-render

Before you optimise anything, you need a mental model of what React is actually doing. When state or props change, React re-renders the component that owns that state — and by default, every child of that component re-renders too, regardless of whether their own props changed. This is called a cascading re-render and it's the single biggest source of preventable work in a React app.

React's reconciler (the Fiber architecture since React 16) works in two phases. The render phase is pure and interruptible — React calls your component functions and builds a Fiber tree representing the new UI. The commit phase is synchronous and side-effectful — React applies DOM mutations, runs layout effects, then passive effects. Only DOM nodes that actually changed get touched in the commit phase. But you still paid the full render phase cost for every component in the subtree.

The key insight is this: React uses referential equality (===) to decide whether props changed. A plain object literal {} created inside a parent component is a new reference every render, even if its contents are identical. That's why memoisation isn't just about expensive calculations — it's primarily about reference stability. Unstable references are the root cause of most unnecessary re-renders.

import React, { useState } from 'react';

function ProductCard({ product, onAddToCart }) {
  console.log(`[ProductCard] rendering: ${product.name}`);
  return (
    <div className="product-card">
      <h3>{product.name}</h3>
      <p>${product.price}</p>
      <button onClick={() => onAddToCart(product.id)}>Add to cart</button>
    </div>
  );
}

function ProductListPage() {
  const [searchQuery, setSearchQuery] = useState('');
  const [cartCount, setCartCount] = useState(0);

  const featuredProduct = { id: 1, name: 'Mechanical Keyboard', price: 149 };
  const handleAddToCart = (productId) => {
    console.log(`Adding product ${productId} to cart`);
    setCartCount(prev => prev + 1);
  };

  return (
    <div>
      <p>Cart: {cartCount} items</p>
      <input
        value={searchQuery}
        onChange={e => setSearchQuery(e.target.value)}
        placeholder="Search products..."
      />
      <ProductCard
        product={featuredProduct}
        onAddToCart={handleAddToCart}
      />
    </div>
  );
}

export default ProductListPage;

React.memo, useMemo and useCallback — what each one actually does

These three APIs are frequently used interchangeably by developers who've half-read the docs. They solve different problems and conflating them leads to both under-optimised and over-engineered code.

React.memo is a higher-order component that wraps a component and tells React: 'Only re-render this component if its props have changed.' It does a shallow equality check on the props object. If every prop passes ===, React reuses the last rendered output entirely — it doesn't even call your component function.

useCallback memoises a function reference. It returns the same function object across renders as long as its dependency array hasn't changed. Its primary job is to create stable references to pass as props to memoised children — without it, React.memo is nearly useless because a new function reference counts as a changed prop.

useMemo memoises the return value of a computation. Use it for expensive calculations that shouldn't run on every render, or to stabilise object and array references that get passed as props. The dependency array works identically to useCallback — the memoised value is only recomputed when a dependency changes.

The rule of thumb: if you're passing a callback to a memoised child, use useCallback. If you're passing a derived object or doing expensive maths, use useMemo. Don't use either just because you can.

import React, { useState, useCallback, useMemo } from 'react';

const ProductCard = React.memo(function ProductCard({ product, onAddToCart }) {
  console.log(`[ProductCard] rendering: ${product.name}`);
  return (
    <div className="product-card">
      <h3>{product.name}</h3>
      <p>${product.price.toFixed(2)}</p>
      <button onClick={() => onAddToCart(product.id)}>Add to cart</button>
    </div>
  );
});

function ProductListPage() {
  const [searchQuery, setSearchQuery] = useState('');
  const [cartCount, setCartCount] = useState(0);
  const [inventory] = useState([
    { id: 1, name: 'Mechanical Keyboard', price: 149, category: 'peripherals' },
    { id: 2, name: 'USB-C Hub', price: 49, category: 'peripherals' },
    { id: 3, name: 'Monitor Arm', price: 89, category: 'accessories' },
  ]);

  const featuredProduct = useMemo(
    () => inventory.find(item => item.id === 1),
    [inventory]
  );

  const filteredInventory = useMemo(() => {
    console.log('[useMemo] recomputing filtered inventory');
    return inventory
      .filter(item =>
        item.name.toLowerCase().includes(searchQuery.toLowerCase())
      )
      .sort((a, b) => a.price - b.price);
  }, [inventory, searchQuery]);

  const handleAddToCart = useCallback((productId) => {
    console.log(`Adding product ${productId} to cart`);
    setCartCount(prev => prev + 1);
  }, []);

  return (
    <div>
      <p>Cart: {cartCount} items</p>
      <input
        value={searchQuery}
        onChange={e => setSearchQuery(e.target.value)}
        placeholder="Search products..."
      />
      <ProductCard
        product={featuredProduct}
        onAddToCart={handleAddToCart}
      />
      <h2>All Products ({filteredInventory.length})</h2>
      {filteredInventory.map(product => (
        <ProductCard
          key={product.id}
          product={product}
          onAddToCart={handleAddToCart}
        />
      ))}
    </div>
  );
}

export default ProductListPage;

Code splitting with React.lazy, Suspense and dynamic imports

Memoisation fights unnecessary re-renders. Code splitting fights the other performance killer: loading too much JavaScript upfront. In a typical React SPA, bundlers like Webpack or Vite produce a single JavaScript bundle. A user visiting your landing page downloads code for your admin dashboard, your analytics charts, and every other route — most of which they'll never touch. This bloats the initial bundle, delays Time to Interactive, and kills Lighthouse scores.

Code splitting lets you split your bundle into smaller chunks that load on demand. React.lazy and Suspense are the built-in APIs for this. React.lazy takes a function that calls a dynamic import() — a browser-native API that returns a Promise resolving to a module. React defers rendering that component until the module has loaded, and Suspense defines what to show in the meantime.

The sweet spot for lazy loading is route-level splitting — each page becomes its own chunk. But it's also valuable for heavy third-party components like rich text editors, PDF viewers, or chart libraries that aren't needed on initial load. The rule: if a user's critical path doesn't need it within the first three seconds, consider lazy loading it.

A critical gotcha: React.lazy only works with default exports. Named exports require a small wrapper. Also, always wrap lazy components high enough in the tree that the Suspense fallback doesn't cause layout shift.

import React, { Suspense, lazy, useState } from 'react';

const AnalyticsDashboard = lazy(() => import('./pages/AnalyticsDashboard'));

const RichTextEditor = lazy(() =>
  import('./components/RichTextEditor').then(module => ({
    default: module.RichTextEditor
  }))
);

function DashboardSkeleton() {
  return (
    <div aria-busy="true" aria-label="Loading analytics dashboard">
      <div style={{ height: 48, background: '#e5e7eb', borderRadius: 8, marginBottom: 16 }} />
      <div style={{ height: 300, background: '#e5e7eb', borderRadius: 8 }} />
    </div>
  );
}

function App() {
  const [activeView, setActiveView] = useState('home');

  return (
    <div>
      <nav>
        <button onClick={() => setActiveView('home')}>Home</button>
        <button onClick={() => setActiveView('analytics')}>Analytics</button>
        <button onClick={() => setActiveView('editor')}>Editor</button>
      </nav>

      {activeView === 'home' && (
        <main>
          <h1>Welcome to the Dashboard</h1>
          <p>Select a section to get started.</p>
        </main>
      )}

      {activeView === 'analytics' && (
        <Suspense fallback={<DashboardSkeleton />}>
          <AnalyticsDashboard dateRange="last-30-days" />
        </Suspense>
      )}

      {activeView === 'editor' && (
        <Suspense fallback={<div>Loading editor...</div>}>
          <RichTextEditor initialContent="Start writing..." />
        </Suspense>
      )}
    </div>
  );
}

export default App;

Virtualisation for long lists — only render what the user can see

No amount of memoisation saves you if you're trying to render 10,000 DOM nodes at once. The browser has to create, style, and layout each one. A list with 5,000 items might take 2–3 seconds just to mount — and that's before any interaction.

Virtualisation (also called windowing) solves this by only rendering the DOM nodes currently visible in the viewport, plus a small overscan buffer above and below. As the user scrolls, nodes are recycled — elements that scroll off the top are repositioned and reused for content coming in from the bottom. The DOM stays small (typically 20–50 nodes) regardless of how many items are in the data set.

@tanstack/react-virtual is the modern, framework-agnostic choice. It's headless — it gives you the calculations, you control the markup. react-window and react-virtualized are older but still widely used in production and worth knowing for legacy codebases.

Critical consideration: virtualisation breaks native browser 'find in page' (Ctrl+F) because non-rendered items aren't in the DOM. For accessibility and search-critical content, consider server-side pagination instead. Also, fixed-height rows are significantly simpler to implement than variable-height rows — @tanstack/react-virtual supports both, but dynamic measurement has its own complexity.

import React, { useRef, useMemo } from 'react';
import { useVirtualizer } from '@tanstack/react-virtual';

function generateProductCatalogue(count) {
  return Array.from({ length: count }, (_, index) => ({
    id: index + 1,
    name: `Product ${index + 1}`,
    price: parseFloat((Math.random() * 500 + 10).toFixed(2)),
    category: ['electronics', 'clothing', 'books', 'tools'][index % 4],
    inStock: index % 7 !== 0,
  }));
}

function ProductRow({ product, style }) {
  return (
    <div
      style={{
        ...style,
        display: 'flex',
        alignItems: 'center',
        padding: '0 16px',
        borderBottom: '1px solid #e5e7eb',
        background: product.inStock ? '#fff' : '#fef2f2',
      }}
    >
      <span style={{ flex: 1, fontWeight: 600 }}>{product.name}</span>
      <span style={{ width: 100, color: '#6b7280' }}>{product.category}</span>
      <span style={{ width: 80, textAlign: 'right' }}>${product.price}</span>
      <span style={{ width: 80, textAlign: 'right', color: product.inStock ? '#16a34a' : '#dc2626' }}>
        {product.inStock ? 'In stock' : 'Sold out'}
      </span>
    </div>
  );
}

function VirtualisedProductList() {
  const allProducts = useMemo(() => generateProductCatalogue(10_000), []);
  const scrollContainerRef = useRef(null);

  const virtualiser = useVirtualizer({
    count: allProducts.length,
    getScrollElement: () => scrollContainerRef.current,
    estimateSize: () => 56,
    overscan: 5,
  });

  const totalScrollHeight = virtualiser.getTotalSize();
  const visibleItems = virtualiser.getVirtualItems();

  console.log(`Rendering ${visibleItems.length} of ${allProducts.length} items in DOM`);

  return (
    <div>
      <h2>Product Catalogue ({allProducts.length.toLocaleString()} items)</h2>
      <div
        ref={scrollContainerRef}
        style={{ height: 600, overflow: 'auto', border: '1px solid #e5e7eb', borderRadius: 8 }}
      >
        <div style={{ height: totalScrollHeight, position: 'relative' }}>
          {visibleItems.map(virtualItem => {
            const product = allProducts[virtualItem.index];
            return (
              <ProductRow
                key={product.id}
                product={product}
                style={{
                  position: 'absolute',
                  top: 0,
                  left: 0,
                  width: '100%',
                  transform: `translateY(${virtualItem.start}px)`,
                  height: `${virtualItem.size}px`,
                }}
              />
            );
          })}
        </div>
      </div>
    </div>
  );
}

export default VirtualisedProductList;

Profiling React Performance: The One Tool You Must Know

All optimisation without profiling is guesswork. The React DevTools Profiler is your single source of truth. It records each render commit, shows which components re-rendered and why, and gives you the flamegraph of where time is spent. Without it, you're flying blind.

To use it: record an interaction (e.g., typing in a search input, clicking a button). The profiler shows each commit as a bar at the top. Click a commit to see a flamegraph. Components that re-rendered are highlighted; their color intensity corresponds to time spent. Hover over a component to see 'why did this render?' — often it's 'Parent re-rendered' or 'Props changed' with the specific prop.

Also enable the 'Highlight updates when components render' option in the React DevTools settings. It overlays colored borders on components that re-render. If you see a border flashing on a component that shouldn't re-render, you've found the leak.

A production-safe pattern: add a debug-only render counter using React.useRef in components. Log out render counts to the console in development. This catches cascading re-renders early without relying on the profiler every time.

import { useRef, useEffect } from 'react';

// A custom hook to track how many times a component renders (development only)
export function useRenderCounter(componentName = 'Component') {
  const renderCount = useRef(0);

  useEffect(() => {
    renderCount.current += 1;
    if (process.env.NODE_ENV === 'development') {
      console.log(`[Render ${componentName}] #${renderCount.current}`);
    }
  });

  return renderCount.current;
}

// Usage inside a component:
// const renderCount = useRenderCounter('ProductCard');
// You can use renderCount to display it on the UI if needed.

When NOT to optimise: the hidden cost of premature optimisation

The React team's own documentation warns against premature memoisation. Here's why: every useMemo and useCallback call allocates memory for a cache entry, runs dependency comparison on every render, and increases the cognitive load of the code. For a simple calculation (e.g., const fullName = ${first} ${last}``), wrapping it in useMemo adds more overhead than the calculation itself.

Similarly, React.memo on a component that re-renders frequently with actually different props is wasted — the comparison runs every render and never skips the re-render anyway. It's pure overhead.

The rule: measure before optimising. Use the profiler to find components that re-render more than expected or take >1ms in the render phase. Apply memoisation only to those. Also, consider restructuring your component tree before reaching for optimisation APIs. Lifting state up or pushing it down often solves the problem without adding any memo calls.

Finally, remember that React 19's compiler (React Forget) aims to auto-memoise components. But that doesn't mean you can ignore these fundamentals today. The compiler understands reference stability and dependencies; you'll still need to write clean component trees.

import React, { useMemo, useCallback } from 'react';

// Bad: useMemo on a trivial string concatenation
function UserGreeting({ firstName, lastName }) {
  const fullName = useMemo(() => `${firstName} ${lastName}`, [firstName, lastName]);
  return <h1>Hello, {fullName}</h1>;
}

// The concatenation is O(1), the useMemo adds allocation and dep check.
// Just write: const fullName = `${firstName} ${lastName}`;

// Also bad: useCallback on a handler passed to a non-memoised child
function Parent() {
  const handleClick = useCallback(() => {
    console.log('clicked');
  }, []);

  // Child is a plain div, not React.memo. useCallback does nothing useful.
  return <div onClick={handleClick}>Click me</div>;
}