Performance: Memoization, Lists, Code Splitting and the React Compiler

"React is slow" is almost never true. What is true is that one screen renders too much, too often, or renders too many DOM nodes. This lesson gives you the tools to see which, and for each one a fix with before and after numbers that I measured.

This is lesson 7 of a ten-lesson series. It uses the render rules from State and Rendering (lesson 1) and the render counts from Context and State Management (lesson 6). The next lesson, Patterns, Server Components and Testing React, covers the structure side of a real app. For an interview-style view of the same ideas see React Rendering Model: Render, Commit, Reconciliation and Keys.

Words used in this lesson

• A render is React calling your component function to get a description of the UI. It is not the same as updating the screen.
• A commit is React applying the changes to the real DOM. Many renders end in a commit that changes nothing.
• Profiler is a React tool that records which components rendered and how long it took. There is a panel in React DevTools, and a <Profiler> component for code.
• Memoization means remembering the result of a calculation so you can reuse it when the inputs are the same.
• memo wraps a component so it skips rendering when its props are shallowly equal to last time.
• Shallow equality means comparing each prop with Object.is. Two different objects with the same content are not equal.
• Referential equality means "is it the very same object in memory?".
• useMemo remembers a calculated value between renders. useCallback remembers a function between renders.
• Virtualisation (windowing) means rendering only the rows you can see, plus a few more, instead of all of them.
• Code splitting means cutting your JavaScript into several files that load when needed.
• lazy is the React function that loads a component's code only when it is first rendered.
• A transition is an update React is allowed to interrupt, so urgent things like typing stay smooth.
• useDeferredValue gives you a copy of a value that lags behind, so slow work can use the old value while the new one is prepared.
• React Compiler is a build-time tool that adds memoization to your components automatically.
• A bundle is the JavaScript file your build produces for the browser.

Rule 0: measure first

The React docs say it clearly in the useMemo page: unless you loop over thousands of objects, a calculation is probably not expensive, and the way to check is to time it. I follow the same discipline for everything here.

There are three ways to measure, from cheap to rich:

1. A render counter. Put console.count("Row") or a counter in the body of a component. I used this for all counts in these lessons. Cheap and exact.
2. The <Profiler> component. It wraps a part of the tree and calls your onRender function after each commit with the time spent.
3. The React DevTools Profiler panel. You press record, use the page, press stop, and get a flame graph. It shows which components rendered and why (for example "props changed" or "hooks changed"). I could not run it in my sandbox, but it is the standard tool for finding the real culprit in a big app.

Here is the <Profiler> component in code. According to the reference, it takes an id and an onRender callback, and the callback gets the phase, the actualDuration (time spent rendering this update) and the baseDuration (an estimate of the cost with no memoization at all):

import { Profiler } from "react";<Profiler id="x" onRender={(id, phase, actual, base) => console.log(phase, actual, base)}>  <Host /></Profiler>

Why does a component render? Three reasons only

A component renders when:

1. It renders for the first time.
2. Its own state changed (or a context it reads changed).
3. Its parent rendered. Yes, even if its props are the same. By default React re-renders the whole subtree below a component that rendered.

Reason 3 is the one that causes most "extra" renders. When you type in an input at the top of a page and the whole page below renders again, this is why. It is also not a bug. Most re-renders are cheap and harmless. They become a problem only when they are slow (heavy work per render) or numerous (thousands of components).

Now we fix the real cases, cheapest fix first.

Fix 1: move state down, or pass children

You met this in lesson 6. If a piece of state changes often (a typed text), keep it in a small component of its own, so the rest of the page is not its child. Or pass the rest as children. Both cost nothing. Always try these first.

Fix 2: memo, and why it fails so easily

memo wraps a component and says: "if the props are the same as last time, skip rendering me".

const MemoRow = memo(function Row({ item, onPick }) { ... });

"The same" means shallowly equal: each prop is compared with Object.is. A string, number or boolean compares by value. An object, array or function compares by identity, and a new {} or () => {} created during a render is a new identity every time.

I measured this with a list of 5 rows and an input box above it. I typed 3 characters, which re-renders the parent 3 times, and counted how many times Row rendered in total:

function Panel({ Comp, mode }) {  const [typed, setTyped] = useState("");  const [picked, setPicked] = useState(null);  const pickInline = (id) => setPicked(id);                    // new function every render  const pickStable = useCallback((id) => setPicked(id), []);   // same function  const onPick = mode === "stable" ? pickStable : pickInline;  return (    <div>      <input aria-label="typed" value={typed} onChange={e => setTyped(e.target.value)} />      <ul>{items.map(it => <Comp key={it.id} item={it} onPick={onPick} />)}</ul>    </div>  );}

plain Row, inline handler                    Row renders: 15memo(Row), inline handler (memo defeated)    Row renders: 15memo(Row), useCallback handler               Row renders: 0

Read the three lines:

• Plain row: 5 rows times 3 keystrokes is 15 renders. All wasted, because no row's data changed.
• memo but an inline function as a prop: still 15. memo is on, but onPick is a new function each render, so the props are never equal. This is the number one reason "memo does not work".
• memo plus useCallback: 0 renders. The function keeps the same identity, item is the same object, so every row is skipped.

So memo only works if every prop is stable. A stable function comes from useCallback, a stable object from useMemo or from moving it outside the component. The React docs say the same, and add a warning about custom comparison functions: if you give memo a second argument arePropsEqual, you must compare every prop including functions, or an old closure will keep seeing old state.

useCallback is only a tool for memo and dependency arrays

useCallback(fn, deps) returns the same function as long as deps do not change. By itself it does nothing useful. It helps in two places only:

1. When you pass the function to a memo child (as above).
2. When the function is in the dependency array of an effect or useMemo, and you do not want that effect to run every render.

A useCallback on a function that is passed to plain <button onClick> buys nothing. DOM elements do not care if the function changed.

Fix 3: useMemo for slow calculations

useMemo(calc, deps) runs calc once and then returns the stored result until a dependency changes.

I made a component that does an honest slow loop (5 million square roots, about 10 milliseconds on my machine) on every render, plus an input. Typing re-renders it. I typed 3 characters and timed the calculation line in each render:

function Plain() {  const [typed, setTyped] = useState("");  const total = slowSum(5_000_000);                            // runs on EVERY render  ...}function Memoed() {  const [typed, setTyped] = useState("");  const total = useMemo(() => slowSum(5_000_000), []);         // runs once  ...}

without useMemo slowSum calls: 4 | render calc times (ms): 13.3, 10.6, 9.6, 10.0with useMemo    slowSum calls: 1 | render calc times (ms): 9.9, 0.1, 0.0, 0.0

Four renders (mount plus 3 keystrokes). Without useMemo the slow function ran 4 times, about 10 ms each. With it, it ran once. On a slow phone that 10 ms could be 50 ms, enough to make typing feel sticky.

The docs give a simple test for "expensive": log the time with console.time; if the total for an interaction is around 1 ms or more, memoising may be worth it. And they remind you that useMemo does not make the first render faster. It only skips repeated work.

When memo, useMemo and useCallback are NOT worth it

• The component renders in under a millisecond. Skipping it is invisible.
• Props change on every render anyway (a fresh array from .map).
• You have not measured a problem.
• The code gets harder to read. Each useCallback with its dependency array is a place for a stale closure bug.

A good rule is the one in the React Compiler docs: for new code, write plain code and let the compiler handle it (next section), and keep manual useMemo/useCallback for precise control.

The Profiler in numbers

To see memo in the Profiler, I made a host with a button and 10 child components that each take about 5 ms to render. I wrapped everything in <Profiler> and clicked the button once, which re-renders the host and children:

no memo update commit -> actualDuration 51.4 ms, baseDuration 51.4 msmemo    update commit -> actualDuration 0.3 ms, baseDuration 51.5 ms

How to read it. actualDuration is what this update really cost. baseDuration is the estimate of what it would cost if nothing was memoized. Without memo, both are about 51 ms (10 children times 5 ms, plus overhead). With memo, actualDuration fell to 0.3 ms, but baseDuration is still about 51 ms. That gap is exactly the benefit: a big gap between the two numbers means memoization is paying off. (This ran in a development build in jsdom, so use it for the shape, not for absolute speed.)

Fix 4: long lists, virtualisation

The biggest practical performance problem in React apps is not renders. It is too many DOM nodes. A table with 10,000 rows, where each row has 5 elements, is 50,000 DOM elements. The browser needs time and memory for each, even if React renders each only once.

Memoization cannot fix that. The fix is windowing: render only the rows that are visible (say 18) plus a small buffer, and move them as the user scrolls. The library react-window (version 2.3.4 here) does this. You give it the row count, a row height and a row component:

import { List } from "react-window";function VRow({ index, style }) {  return <div style={style}><Row item={data[index]} /></div>;}<List rowComponent={VRow} rowCount={data.length} rowHeight={28} rowProps={{}} style={{ height: 400 }} />

I built the same 10,000-row list two ways, each row with a bold id, a name, an email and a button. I bundled with esbuild in production mode and loaded it in headless Chromium 141 with Playwright. "Render ms" is the time inside flushSync(root.render(...)), which includes React rendering and committing. "Until paint" is the time until two animation frames later, so it includes the browser's layout work. Three runs:

{"mode":"full","renderMs":139,"untilPaintMs":790,"domNodes":50006,"rows":10000,"heapMB":19.6}{"mode":"virtual","renderMs":16,"untilPaintMs":75,"domNodes":115,"rows":18,"heapMB":9.5}{"mode":"full","renderMs":500,"untilPaintMs":1727,"domNodes":50006,"rows":10000,"heapMB":19.6}{"mode":"virtual","renderMs":15,"untilPaintMs":59,"domNodes":115,"rows":18,"heapMB":9.5}{"mode":"full","renderMs":627,"untilPaintMs":1808,"domNodes":50006,"rows":10000,"heapMB":19.6}{"mode":"virtual","renderMs":17,"untilPaintMs":68,"domNodes":115,"rows":18,"heapMB":9.5}

What the numbers say:

The exact milliseconds vary a lot on my sandbox machine (look at the full-list column: 139, 500, 627), so trust the shape, not the digits. The counts are stable: 50,006 nodes against 115. A user with a slower phone would see the full list freeze for seconds.

What virtualisation costs you:

• Row heights. The library needs to know row heights (fixed is simplest and fastest. The docs warn that dynamic heights are less efficient).
• Find in page and screen readers. Rows that are not in the DOM cannot be found with Ctrl+F, and assistive tech sees only the rendered ones. For tables, think about accessibility and pagination.
• Layout complexity. Sticky headers, variable columns and "scroll to item" need care.

If your list has under about 100 to 200 simple rows, do not bother. For thousands, virtualise. Often the best option is plain pagination or "load more", because users rarely need 10,000 rows on one page.

Fix 5: code splitting with lazy and Suspense

Rendering speed is half of the story. The other half is how much JavaScript the browser must download and run before the page works. A chart library or a rich text editor can add hundreds of kilobytes that most users never open. lazy loads a component's code only when it is first rendered:

import { lazy, Suspense, useState } from "react";const Heavy = lazy(() => import("./Heavy.jsx"));   // call lazy OUTSIDE componentsfunction App() {  const [show, setShow] = useState(false);  return (    <div>      <button onClick={() => setShow(true)}>show chart</button>      {show && (        <Suspense fallback={<p>loading chart...</p>}>          <Heavy />        </Suspense>      )}    </div>  );}

Two rules from the lazy reference: call lazy at the top level of a module (not inside a component, or the state resets on each render), and the import() must resolve to an object whose default is a component. While the code loads, the component suspends and the nearest Suspense shows its fallback.

I measured it with esbuild's --splitting. As a stand-in "heavy" component, I used one that imports Redux Toolkit. First, importing it normally:

l7/split/eager/main-eager.js  240.1kb      (gzip: 77,573 bytes)

Then with lazy(() => import("./Heavy.jsx")):

main-lazy.js         217.3kb   (gzip: 68,985 bytes)Heavy-S7FRMRON.js     21.7kb   (gzip:  8,705 bytes)chunk-AXYECJVO.js      1.3kb

The first load now ships 217 kB instead of 240 kB (about 8.6 kB gzipped less), and the 21.7 kB for the heavy part loads only when the user clicks. The saving here is small because my "heavy" part is small. With a real chart or editor library of 300 kB, the effect is large. The method is the same: find big parts that are not needed on first paint, and lazy load them.

Good places to split: routes (each page loads on navigation), modals, charts, rich text editors, and rarely used admin screens. Bad places: tiny components, or things needed right away (you will just add a spinner).

Fix 6: transitions and useDeferredValue for slow updates you cannot make fast

Sometimes the work is really slow and cannot be skipped: filtering and rendering a big result list on each keystroke. The input should still feel instant. React lets you say "this update is not urgent":

• useTransition gives you startTransition(fn) and isPending. State updates inside fn are low priority. If something urgent comes in (the user types again), React can drop the old low-priority render and start over.
• useDeferredValue(value) gives you a copy of value that lags behind. React first renders with the old value (fast), then tries to render with the new value in the background.

function Search() {  const [q, setQ] = useState("");  const dq = useDeferredValue(q);             // lags behind q  return (    <div>      <input value={q} onChange={(e) => setQ(e.target.value)} />   {/* urgent: uses q */}      <Results query={dq} />                                        {/* slow: uses dq */}    </div>  );}const Results = memo(function Results({ query }) { /* 100 slow items */ });

Note the memo on Results. When only q changes and dq still has the old value, Results gets the same props and is skipped, which is how the first, fast render stays fast.

I tested this in Chromium. Results renders 100 items, each costing about 0.2 ms of busy work. I typed 8 characters with Playwright (keyboard.type with no delay) and counted how many times Results rendered. I ran it four times:

plain:    resultsRenders 8, 8, 8, 8        keystrokes took 283 to 303 msdeferred: resultsRenders 4, 5, 7, 8        keystrokes took 116 to 238 ms

With the plain version, every one of the 8 keystrokes blocked the page while the results rendered: 8 renders, about 290 ms. With useDeferredValue, React often skipped intermediate values: between 4 and 8 renders, and typing finished faster. But the result varied between runs, and in the last run it did all 8. Deferring does not promise fewer renders. It promises that urgent updates (typing) are not stuck behind the slow ones. It helps most when the slow part is really slow, or the user types quickly. If your slow work is only 20 ms, you may see no difference.

The docs also mention two things about these tools:

• Transition updates cannot control a text input. The input's own value must be urgent state (that is why I use q for the input and dq for the results).
• With Suspense, a transition or a deferred value keeps showing the old content while the new content loads, instead of the fallback spinner. isPending lets you dim the old content.

const [isPending, startTransition] = useTransition();<button onClick={() => startTransition(() => setTab("posts"))}>Posts</button><div style={{ opacity: isPending ? 0.6 : 1 }}>...</div>

React Compiler: memoization that writes itself

Writing memo, useMemo and useCallback by hand is tedious and easy to get wrong (I showed above how one inline function defeats memo). The React Compiler is a build-time tool that adds this memoization for you. The React docs say it is now stable, understands the "Rules of React", and has been used in production at Meta. It is a Babel plugin (babel-plugin-react-compiler), also supported through Vite and Next.js 15.3.1 and newer. It works best with React 19 and also supports React 17 and 18 through a target setting.

What does it actually do? I compiled a small component with the real plugin (version 1.0.0) and read the output. The input:

export function List({ items, onPick }) {  const [typed, setTyped] = useState("");  const shown = items.filter(i => i.name.includes(typed));  return (<div>    <input value={typed} onChange={e => setTyped(e.target.value)} />    <ul>{shown.map(i => <Row key={i.id} item={i} onPick={() => onPick(i.id)} />)}</ul>  </div>);}

The compiled output (shortened, but real):

import { c as _c } from "react/compiler-runtime";export function List(t0) {  const $ = _c(17);                       // a cache array with 17 slots  const { items, onPick } = t0;  const [typed, setTyped] = useState("");  ...  if ($[0] !== items || $[1] !== onPick || $[2] !== typed) {    ...    const shown = items.filter(t3);    ...    t1 = shown.map(t5);    $[0] = items; $[1] = onPick; $[2] = typed; $[3] = t1; $[4] = t2;  } else {    t1 = $[3];    t2 = $[4];  }  ...}

Read this like a human. The compiler creates a small cache array $ for the component. Before computing a piece, it checks "are my inputs the same as last time?" ($[0] !== items ...). If they are the same, it reuses the stored value (t1 = $[3]). That is useMemo and useCallback applied everywhere, even to JSX elements, which is something people rarely do by hand. Note the handler e => setTyped(...) is cached once with a sentinel check, so it never changes.

Then I ran my earlier experiment again. Same component as before: an input and 5 rows, with a new inline function passed as a prop, and no memo, useMemo or useCallback anywhere. I compiled the file with the plugin and ran the same typing test on the plain file and on the compiled file:

plain code, no memo anywhere     Row renders for 3 keystrokes: 15same code after React Compiler   Row renders for 3 keystrokes: 0

Fifteen renders to zero, with no change to the source code. That is the promise of the compiler, shown with a real run.

What to know before using it:

• Install. npm install -D babel-plugin-react-compiler@latest, and in Babel it must run first in the plugin list, per the docs. The install page also suggests the eslint-plugin-react-hooks rules that point out code the compiler cannot handle.
• It follows the Rules of React. Components must be pure, state must not be mutated, hooks must be called at the top level. Code that breaks the rules may be skipped or may behave in surprising ways. The compiler skips what it cannot prove safe.
• Adoption can be gradual. The docs show compilationMode: 'annotation', where only components marked with "use memo" are compiled. You can also opt a component out with "use no memo".
• It memoizes components and hooks only. The docs point out that a plain helper function called from a component, even an expensive one, is not memoized across components. If a calculation is really expensive and used in many places, add your own caching around it.
• Keep your old useMemo and useCallback. The docs recommend leaving existing memoization in place, because removing it can change the compiled output. For new code, write plain code and add useMemo/useCallback only when you need precise control. A common reason is a value used as an effect dependency, where you want exact control over when the effect runs.
• It does not fix everything. It will not virtualise your list, shrink your bundle, or make a slow function fast. It reduces extra re-renders. Fixes 1, 4, 5 and 6 are still yours.

A simple checklist for a slow screen

1. Reproduce it, in a production build if you can. Throttle the CPU in the browser tools to imitate a phone.
2. Record with the Profiler. Which component is slow, and why did it render?
3. Is it too many DOM nodes? Virtualise or paginate.
4. Is it too much JavaScript on load? Split by route, lazy load heavy parts, check what is in the bundle.
5. Is it a render that should not happen? Move state down, pass children, stabilise props, then memo.
6. Is it one slow calculation? useMemo it, or move the work (server, worker, precompute).
7. Is it slow but unavoidable, and typing suffers? A transition or useDeferredValue.
8. Check again with numbers. If nothing improved, undo the change.

Try it

Use a scratch Vite project.

1. Make a parent with an input and a list of 200 rows, each row doing a 1 ms busy loop. Type quickly and feel the lag. Add console.count("Row") in Row and count renders for 5 keystrokes.
2. Wrap Row in memo. Does the count change? Why or why not? Then add the right fix for the prop that breaks it.
3. Add a slowSum calculation in the parent that does not depend on the input. Time it with console.time. Wrap it in useMemo. Time it again.
4. Render 10,000 rows twice: all at once, and with react-window. Compare the number of DOM nodes in the browser console with document.getElementsByTagName("*").length.
5. Move a big import behind lazy and look at the network panel. When is the extra file requested?
6. Make the results list slow (100 items at 0.2 ms) and add useDeferredValue. Type fast. Count result renders. Is it always fewer?
7. If your build tool supports it, add babel-plugin-react-compiler and run exercise 2 again without any memo.

Answers

1. 200 rows times 5 keystrokes is 1000 renders and about 200 ms per keystroke, which you can feel.
2. If you pass an inline function or a fresh array/object as a prop, the count does not change, because memo sees new props every time. Wrap the function in useCallback (and objects in useMemo), and the count drops to 0 for typing.
3. Without useMemo, the time is logged on every keystroke. With useMemo and correct dependencies, it is logged once at full cost, then near 0.
4. About 50,000 nodes with 10,000 five-element rows against about a hundred with virtualisation (my numbers: 50,006 against 115).
5. The heavy file is requested only when the lazy component first renders, for example after the click.
6. Not always. In my four runs the result renders were 4, 5, 7 and 8 against a constant 8. The benefit is a more responsive input, not a promised drop in render count.
7. The count for the compiled file should drop to 0 without memo, as in my run (15 to 0).

Interview questions

Key takeaways

• Measure before you optimise: render counters, the <Profiler> component, the DevTools Profiler. Profiling is off in production builds by default.
• A component renders because it is new, its state or context changed, or its parent rendered. Most re-renders are harmless.
• Cheapest fixes first: move state down, or pass children.
• memo needs every prop to be stable. One inline function made memo useless (15 renders), and useCallback fixed it (0).
• useMemo helps only for really slow work or stable identities: 4 slow calls became 1. useCallback alone does nothing, it matters only with memo or dependency arrays.
• Long lists are a DOM problem: 50,006 nodes became 115 with virtualisation.
• lazy plus Suspense moves optional code out of the first bundle. Transitions and useDeferredValue keep typing responsive, but do not make slow code fast.
• The React Compiler adds memoization automatically: 15 renders to 0 on unchanged source. It follows the Rules of React, memoizes components and hooks only, and does not replace virtualisation or code splitting.

What's next

Next: Patterns, Server Components and Testing React. Fast code still has to be well organised and safe. You will see composition patterns, error boundaries that really catch (and do not catch) errors, portals, Server and Client Components in plain words, and a Testing Library test that really runs. To practise now, do exercises 1 and 2 and write down the render counts before and after your fix.