React Performance Patterns: Rendering, Memoization, and Scheduling

Patterns for keeping React applications fast as they scale: understanding the render pipeline, applying memoization correctly, leveraging concurrent features, and profiling effectively. Covers React 18+ with notes on React 19 and the React Compiler.

Abstract

React performance optimization reduces to one question: which components render, and how often?

The render phase calls component functions and diffs the virtual DOM (VDOM). Memoization (memo, useMemo, useCallback) skips renders when inputs haven’t changed—but only if those inputs are referentially stable. Object.is comparison means new object/function references break memoization.

React 18’s concurrent rendering makes the render phase interruptible. Transitions (useTransition, useDeferredValue) let you mark updates as non-urgent so user interactions remain responsive during expensive renders.

For large lists, virtualization renders only visible items, keeping DOM size constant regardless of data size.

Profile with React DevTools Profiler to find actual bottlenecks—measure before optimizing.

The Render Pipeline

When Components Render

A component renders when:

1. Its state changes via a set function
2. Its parent re-renders (unless memoized with stable props)
3. A context it consumes changes

Rendering means React calls your component function. It does not necessarily mean DOM updates—that happens only if the reconciliation diff finds changes.

Render vs. Commit

React separates work into two phases:

The render phase is pure computation. React may call components multiple times, pause rendering, or discard work entirely. The commit phase applies changes to the DOM synchronously—once React starts committing, it runs to completion.

Reconciliation: The O(n) Diff

Comparing arbitrary trees is O(n³). React uses two heuristics to achieve O(n):

1. Different element types produce different trees. Changing <div> to <span> unmounts the entire subtree and rebuilds from scratch.
2. Keys identify stable children. Without keys, React matches children by position—reordering causes unnecessary unmount/remount cycles.

1
// Without keys: inserting at index 0 remounts ALL items
2
<ul>
3
  {items.map(item => <li>{item.name}</li>)}
4
</ul>
5

6
// With keys: React matches by identity, only new items mount
7
<ul>
8
  {items.map(item => <li key={item.id}>{item.name}</li>)}
9
</ul>

Key gotcha: Using array index as key breaks when items reorder or filter. Component state stays with the index, not the data. Use stable IDs from your data.

Fiber Architecture

React Fiber (introduced in React 16) represents components as a linked list of “fiber” nodes rather than a recursive call stack. Each fiber holds:

• Component type and props
• Corresponding DOM node
• Links to parent, child, and sibling fibers
• Pending work and priority

This structure enables incremental rendering: React can pause mid-render, handle a higher-priority update, then resume. It uses double-buffering—maintaining a “current” tree (on screen) and a “work-in-progress” tree (being built)—and swaps pointers on commit.

Prior to React 16: Reconciliation was synchronous and recursive. Once a render started, it blocked the main thread until completion. Deep component trees caused frame drops.

Memoization Patterns

When Memoization Helps

Memoization skips work when inputs haven’t changed. It helps when:

1. A component re-renders frequently with identical props
2. The component’s render is expensive (complex calculations, many children)
3. You’re passing callbacks to memoized children

It doesn’t help when:

• Props always change (new objects/functions every render)
• Render cost is negligible
• The component rarely re-renders anyway

React.memo: Skipping Re-renders

memo wraps a component to skip re-rendering when props are shallowly equal:

3 collapsed lines
1
import { memo } from "react"
2

3
interface ChartProps {
4
  data: number[]
5
  color: string
6
}
7

8
// Only re-renders if data or color reference changes
9
const Chart = memo(function Chart({ data, color }: ChartProps) {
10
  // Expensive rendering logic
11
  return <canvas>{/* ... */}</canvas>
12
})
13

14
// Parent component
4 collapsed lines
15
function Dashboard() {
16
  const [filter, setFilter] = useState("all")
17
  // ...
18
}

How it works: React compares each prop using Object.is. For primitives, this compares values. For objects and functions, it compares references—a new object {} is never equal to a previous {}.

Custom comparison: For deep comparisons, pass a second argument:

1
const Chart = memo(
2
  function Chart({ dataPoints }: { dataPoints: Point[] }) {
3
    /* ... */
4
  },
5
  (prevProps, nextProps) => {
6
    // Return true to skip re-render, false to re-render
7
    return (
8
      prevProps.dataPoints.length === nextProps.dataPoints.length &&
9
      prevProps.dataPoints.every((p, i) => p.x === nextProps.dataPoints[i].x && p.y === nextProps.dataPoints[i].y)
10
    )
11
  },
12
)

Danger: Custom comparers must compare all props. Skipping a callback prop causes stale closures—the component sees outdated state.

useMemo: Caching Computed Values

useMemo caches a calculated value, recomputing only when dependencies change:

5 collapsed lines
1
import { useMemo, useState } from "react"
2

3
interface Todo {
4
  id: string
5
  text: string
6
  completed: boolean
7
}
8

9
function TodoList({ todos, filter }: { todos: Todo[]; filter: string }) {
10
  // filterTodos only runs when todos or filter changes
11
  const visibleTodos = useMemo(() => filterTodos(todos, filter), [todos, filter])
12

13
  return <List items={visibleTodos} />
14
}

Dependency comparison: React uses Object.is on each dependency. If you create a new object in the component body and use it as a dependency, useMemo recalculates every render—defeating its purpose.

1
function Search({ items }: { items: Item[] }) {
2
  const [query, setQuery] = useState("")
3

4
  // ❌ Bad: options object is new every render
5
  const options = { caseSensitive: false, query }
6

7
  const results = useMemo(
8
    // Recalculates every render because options changed
9
    () => searchItems(items, options),
10
    [items, options],
11
  )
12
}

Fix: Move the object creation inside useMemo, or memoize the options object separately:

1
function Search({ items }: { items: Item[] }) {
2
  const [query, setQuery] = useState("")
3

4
  // ✅ Object created inside useMemo, dependencies are primitives
5
  const results = useMemo(() => {
6
    const options = { caseSensitive: false, query }
7
    return searchItems(items, options)
8
  }, [items, query])
9
}

useCallback: Stable Function References

useCallback returns the same function reference across renders when dependencies haven’t changed:

3 collapsed lines
1
import { useCallback, useState } from "react"
2

3
const MemoizedChild = memo(function Child({ onClick }: { onClick: () => void }) {
4
  return <button onClick={onClick}>Click</button>
5
})
6

7
function Parent() {
8
  const [count, setCount] = useState(0)
9

10
  // Same function reference as long as count hasn't changed
11
  const handleClick = useCallback(() => {
12
    console.log("Count:", count)
3 collapsed lines
13
  }, [count])
14

15
  return <MemoizedChild onClick={handleClick} />
16
}

Relationship to useMemo: useCallback(fn, deps) is equivalent to useMemo(() => fn, deps). Both cache values; useCallback is specialized for functions.

Common mistake—stale closures:

1
function Counter() {
2
  const [count, setCount] = useState(0)
3

4
  // ❌ Bad: empty deps means count is always 0 in the closure
5
  const increment = useCallback(() => {
6
    setCount(count + 1) // Always sets to 1
7
  }, [])
8

9
  // ✅ Good: use updater function to avoid dependency
10
  const increment = useCallback(() => {
11
    setCount((c) => c + 1) // Works correctly
12
  }, [])
13
}

When NOT to Memoize

Memoization has overhead: storing cached values, comparing dependencies. For cheap operations, the overhead exceeds the savings.

Skip memoization when:

• The operation is fast (most operations are)
• Props always change anyway
• You’re optimizing without measuring
• The component rarely re-renders

Rule of thumb: If you’re not passing the value to a memoized child or the calculation doesn’t measurably impact performance (1ms+ in profiler), skip the memoization.

React Compiler: Automatic Memoization

React Compiler (currently in beta) analyzes your code at build time and automatically inserts memoization. It makes manual memo, useMemo, and useCallback largely unnecessary:

1
// No manual memoization needed—compiler handles it
2
function TodoList({ todos, filter }) {
3
  const visibleTodos = filterTodos(todos, filter)
4
  return <List items={visibleTodos} />
5
}

The compiler applies memoization correctly based on data flow analysis, avoiding the pitfalls of manual dependency arrays. It requires code to follow React’s rules (components are pure, hooks follow the rules of hooks). Codebases with impure components may need fixes before the compiler works correctly.

Concurrent Rendering

What Changed in React 18

React 18 introduced concurrent rendering—the render phase can be interrupted, paused, and resumed. This is opt-in: you only get concurrent behavior when using concurrent features (useTransition, useDeferredValue, Suspense for data).

Transitions: Urgent vs. Non-Urgent Updates

useTransition marks state updates as non-urgent. React handles urgent updates (typing, clicking) first, then resumes transition updates:

4 collapsed lines
1
import { useState, useTransition } from "react"
2

3
function TabContainer() {
4
  const [tab, setTab] = useState("home")
5
  const [isPending, startTransition] = useTransition()
6

7
  function selectTab(nextTab: string) {
8
    startTransition(() => {
9
      // This update is non-urgent
10
      setTab(nextTab)
11
    })
12
  }
13

14
  return (
15
    <div>
16
      <TabButtons onSelect={selectTab} isPending={isPending} />
17
      <div style={{ opacity: isPending ? 0.7 : 1 }}>
18
        <TabContent tab={tab} />
19
      </div>
20
    </div>
21
  )
22
}

How it works:

1. User clicks a tab → startTransition called
2. isPending becomes true immediately
3. React starts rendering the new tab in the background
4. If user types in an input, React interrupts the tab render to handle the urgent input update
5. Once the tab render completes and no urgent updates are pending, React commits

Critical limitation: Don’t use transitions for controlled input state. The input value must update synchronously for the input to feel responsive:

1
function SearchForm() {
2
  const [query, setQuery] = useState("")
3

4
  // ❌ Bad: input feels laggy
5
  const handleChange = (e) => startTransition(() => setQuery(e.target.value))
6

7
  // ✅ Good: separate state for input vs. results
8
  const [inputValue, setInputValue] = useState("")
9
  const [searchQuery, setSearchQuery] = useState("")
10

11
  const handleChange = (e) => {
12
    setInputValue(e.target.value) // Urgent
13
    startTransition(() => setSearchQuery(e.target.value)) // Deferred
14
  }
15
}

useDeferredValue: Deferring Derived State

useDeferredValue defers updating a value, showing stale content while fresh content renders in the background:

4 collapsed lines
1
import { useState, useDeferredValue, Suspense } from "react"
2

3
function SearchPage() {
4
  const [query, setQuery] = useState("")
5
  const deferredQuery = useDeferredValue(query)
6
  const isStale = query !== deferredQuery
7

8
  return (
9
    <>
10
      <input value={query} onChange={(e) => setQuery(e.target.value)} />
11
      <div style={{ opacity: isStale ? 0.5 : 1 }}>
12
        <Suspense fallback={<Spinner />}>
13
          <SearchResults query={deferredQuery} />
14
        </Suspense>
15
      </div>
16
    </>
17
  )
18
}

Difference from useTransition:

• useTransition: You control the state setter. Wrap the update in startTransition.
• useDeferredValue: You receive a prop/value you don’t control. Defer the value itself.

Difference from debouncing:

Suspense for Data Fetching

Suspense lets components “wait” for data, showing a fallback until ready:

3 collapsed lines
1
import { Suspense } from "react"
2

3
function ProfilePage({ userId }: { userId: string }) {
4
  return (
5
    <Suspense fallback={<ProfileSkeleton />}>
6
      <ProfileDetails userId={userId} />
7
      <Suspense fallback={<PostsSkeleton />}>
8
        <ProfilePosts userId={userId} />
9
      </Suspense>
10
    </Suspense>
11
  )
12
}
13

14
// Components use Suspense-enabled data fetching
15
function ProfileDetails({ userId }) {
3 collapsed lines
16
  const user = use(fetchUser(userId)) // Suspends until resolved
17
  return <h1>{user.name}</h1>
18
}

Nested Suspense boundaries create a reveal sequence:

1. Show ProfileSkeleton while ProfileDetails loads
2. Once ProfileDetails ready, show it + PostsSkeleton for posts
3. Once posts ready, show everything

Transitions + Suspense: Without a transition, suspending hides already-shown content and shows the fallback. With a transition, React keeps showing the current content until the new content is ready:

1
function Router() {
2
  const [page, setPage] = useState("/")
3

4
  function navigate(url: string) {
5
    startTransition(() => setPage(url)) // Keeps current page visible
6
  }
7
}

List Virtualization

The Problem with Large Lists

Rendering 10,000 list items creates 10,000 DOM nodes. Each node consumes memory, and the browser must calculate layout/styles for all of them. Scrolling triggers repaints across the entire tree.

Virtualization renders only visible items (plus a small buffer), maintaining a constant DOM size regardless of list length.

react-window

react-window is a lightweight virtualization library. Two main components:

FixedSizeList: For items with uniform heights

6 collapsed lines
1
import { FixedSizeList } from "react-window"
2

3
interface RowProps {
4
  index: number
5
  style: React.CSSProperties
6
  data: string[]
7
}
8

9
function Row({ index, style, data }: RowProps) {
10
  return <div style={style}>{data[index]}</div>
11
}
12

13
function VirtualizedList({ items }: { items: string[] }) {
14
  return (
15
    <FixedSizeList
16
      height={400}
17
      width="100%"
18
      itemCount={items.length}
19
      itemSize={50} // Each row is 50px tall
20
      itemData={items}
21
      overscanCount={5} // Render 5 extra items above/below viewport
22
    >
4 collapsed lines
23
      {Row}
24
    </FixedSizeList>
25
  )
26
}

VariableSizeList: For items with dynamic heights

4 collapsed lines
1
import { VariableSizeList } from "react-window"
2

3
function getItemSize(index: number): number {
4
  // Return height for item at index
5
  return items[index].isExpanded ? 200 : 50
6
}
7

8
function VirtualizedList({ items }) {
9
  return (
10
    <VariableSizeList height={400} width="100%" itemCount={items.length} itemSize={getItemSize}>
11
      {Row}
12
    </VariableSizeList>
13
  )
14
}

The style prop is mandatory—it positions items absolutely within the scroll container.

Overscan

overscanCount renders items outside the visible window to prevent white flashes during fast scrolling. Higher values improve smoothness but reduce performance gains. Start with 2-5 and increase if you see flashing.

Limitations

• Browser search (Ctrl+F) doesn’t find non-rendered items. Implement custom search that calculates positions and scrolls to matches.
• Accessibility: Screen readers may not announce off-screen items. Test with assistive technology.
• Dynamic heights: Variable-size lists must know item heights upfront. For truly dynamic content, measure heights and cache them.

Profiling

React DevTools Profiler

The Profiler records component renders and timing:

1. Open React DevTools → Profiler tab
2. Click record, interact with your app, click stop
3. Review the flame graph

Flame graph reading:

• Each bar = one component render
• Width = time spent rendering (component + children)
• Color: blue (fast), yellow (medium), red (slow)
• Gray = component didn’t render

Ranked chart: Shows components sorted by self-time (excluding children). Use this to find individual slow components.

The <Profiler> Component

For programmatic measurement:

4 collapsed lines
1
import { Profiler, ProfilerOnRenderCallback } from "react"
2

3
const onRender: ProfilerOnRenderCallback = (id, phase, actualDuration, baseDuration, startTime, commitTime) => {
4
  console.log({
5
    id, // Profiler id prop
6
    phase, // "mount" | "update" | "nested-update"
7
    actualDuration, // Time spent rendering (with memoization)
8
    baseDuration, // Time without any memoization (worst case)
9
  })
10
}
11

12
function App() {
13
  return (
14
    <Profiler id="App" onRender={onRender}>
15
      <MainContent />
16
    </Profiler>
17
  )
18
}

Compare actualDuration to baseDuration to verify memoization effectiveness. If they’re similar, memoization isn’t helping.

Profiling in Production

Development builds include extra checks that slow rendering. Production builds are 2-10x faster. For accurate measurements:

1. Use a profiling build: react-dom/profiling instead of react-dom
2. Measure in production-like conditions
3. Test on representative hardware (not just developer machines)

“Why Did This Render?”

Enable “Record why each component rendered while profiling” in DevTools settings. After recording, select a component to see why it re-rendered:

• “Props changed” (lists which props)
• “State changed”
• “Context changed”
• “Parent re-rendered”

This pinpoints unnecessary renders immediately.

Performance Checklist

Rendering

• Use key with stable, unique IDs (not array index)
• Keep state as local as possible
• Split large components so state changes affect smaller subtrees

Memoization

• Apply memo to components that re-render frequently with same props
• Ensure memoized components receive stable references (primitives or memoized objects/functions)
• Use useMemo for expensive calculations with stable dependencies
• Use useCallback for callbacks passed to memoized children

Concurrent Features

• Wrap expensive, non-urgent updates in startTransition
• Use useDeferredValue for values that don’t need immediate updates
• Show visual feedback (isPending, opacity reduction) during transitions

Large Lists

• Virtualize lists with 100+ items using react-window
• Set appropriate overscanCount (2-5 typically)
• Implement custom search if users need Ctrl+F functionality

Profiling

• Profile with React DevTools before optimizing
• Use production profiling builds for accurate measurements
• Enable “why did this render” to find unnecessary re-renders
• Verify memoization helps by comparing actualDuration vs baseDuration

Conclusion

React performance follows a hierarchy:

1. Minimize render frequency. Keep state local, lift only what’s necessary, use proper keys.
2. Skip unnecessary renders. Apply memoization where profiling shows benefit.
3. Make renders interruptible. Use transitions for non-urgent updates.
4. Reduce DOM size. Virtualize large lists.

Measure before optimizing. Most React apps don’t need aggressive optimization—the framework is fast by default. When you do optimize, profile to find actual bottlenecks rather than guessing.

Appendix

Prerequisites

• React component model (props, state, effects)
• JSX and rendering basics
• JavaScript reference equality (===, Object.is)

Terminology

• VDOM (Virtual DOM): In-memory representation of the UI that React diffs against the previous version to determine minimal DOM updates.
• Reconciliation: The process of diffing the old and new VDOM trees to compute the minimal set of changes.
• Fiber: React’s unit of work representing a component instance; enables incremental rendering.
• Commit: The phase where React applies changes to the actual DOM.
• Transition: A non-urgent update that can be interrupted by urgent updates.

Summary

• Render frequency is the primary performance lever—reduce unnecessary component calls
• Memoization (memo, useMemo, useCallback) works only with referentially stable inputs
• Concurrent features (useTransition, useDeferredValue) keep UI responsive during expensive updates
• Virtualization renders only visible items, maintaining constant DOM size
• Profile first, optimize second—React DevTools shows where time is actually spent

References

• React: Render and Commit - Official docs on the render pipeline
• Reconciliation (Legacy Docs) - O(n) diffing algorithm details
• React.memo - Component memoization API
• useMemo - Value memoization hook
• useCallback - Callback memoization hook
• useTransition - Transition hook API
• useDeferredValue - Deferred value hook API
• Suspense - Suspense component API
• React 18 Release Notes - Concurrent features announcement
• React Fiber Architecture - Andrew Clark’s explanation of Fiber
• react-window - List virtualization library
• Virtualize long lists with react-window - web.dev guide
• Profiler API - Programmatic profiling component