Profiling React apps

Find the slow part before you fix it

When a page feels slow, it's tempting to guess which part is to blame and start changing code. Guesses are often wrong. Profiling means measuring the page while it runs: which components rendered, how long each one took, and why it rendered at all. Then you fix the part that really took the time. Here is a small tea shop with a search box. The result is live: click in the box and type mint quickly.

1import { useState } from "react";2import ProductList from "./ProductList.jsx";3import Recommendations from "./Recommendations.jsx";4 5function CartBadge({ count }) {6  return <p>Cart: {count}</p>;7}8 9export default function ShopPage() {10  const [query, setQuery] = useState("");11  const [cartCount, setCartCount] = useState(0);12  return (13    <>14      <CartBadge count={cartCount} />15      <input value={query} onChange={(e) => setQuery(e.target.value)} placeholder="Search teas" />16      <ProductList query={query} onAdd={() => setCartCount(cartCount + 1)} />17      <Recommendations />18    </>19  );20}

Line 10 keeps the search query in state, and line 11 the cartCount. Line 14 shows the count with CartBadge (lines 5 to 7). Line 15 is the search box. Line 16 renders ProductList, which filters four teas by the query in its tab, and gives each an Add button. Line 17 renders Recommendations, 15 picks from the Recommendations.jsx tab.

The letters appear late, a few at a time. Which part is slow? ProductList does the searching, so it looks like the one to blame. It isn't. Open the Recommendations.jsx tab: lines 3 to 6 make each Pick wait 3 milliseconds on purpose, like a card with a lot to draw. 15 picks take at least 45 milliseconds, and about twice that in development, because StrictMode calls every component twice (the Keeping components pure lesson explains why). The picks don't use the query at all, yet every key draws them again. You couldn't tell that by reading App.jsx. A profile shows it in one look, and this lesson shows you how to take one.

Record a profile in React DevTools

React DevTools is a browser extension for Chrome, Firefox, and Edge. The Setting up a React project lesson installs it and uses its Components tab. Its other tab, Profiler, records your app while you use it. On a page made with React, open the browser's developer tools and choose the Profiler tab. Then:

1. Press the round Start profiling button (the record button) at the top left of the tab.
2. Do the slow thing in the page, and only that: type a few letters in the search box.
3. Press the button again to stop.

The Profiler groups what it saw by commit. As Render and commit showed, React first renders (calls your components to find out what changed), then commits (puts the changes on the page). Each key you typed made one render and one commit. A row of small bars at the top right of the tab is the list of commits: one bar per commit, taller and warmer in color when it took longer. Click a bar to look at that commit.

The Profiler can draw a commit in two ways, as two charts you switch between at the top of the tab:

• The Flamegraph draws the component tree: each bar is a component, with its children in the row below it. A bar's width is how long that component and its children took the last time they rendered. Its color shows how long the component took on its own in this commit, from cool (quick) to yellow (slow). A gray bar is a component that didn't render in this commit at all. Each bar's label reads like Recommendations (0.2ms of 45.2ms): the component's own time, then its time with its children.
• The Ranked chart lists only the components that rendered in this commit, one per row, sorted by their own time, slowest first. A slow component deep in the tree comes up to the top.

The Profiler only shows components, not the <input> or <li> elements inside them. Hover over a bar for a summary. Click it, and the chart zooms in on that component, and the panel on the right lists every commit it rendered in, under Rendered at.

You can try all of this without the extension. The playground runs the same shop on this page, next to a small model of the Profiler tab. Type in its search box and press Add: each change adds a commit. Click a commit bar, switch between Flamegraph and Ranked, and click the bars. Then choose Recommendations in memo and type again.

With plain Recommendations, every commit after a key has the same picture: Recommendations and its 15 picks rendered, and they make up almost all of the commit's time. With Recommendations in memo, the first render is the same, but after that the picks are gray when you type. The flamegraph keeps them just as wide, since a bar's width is the time from the last render it did, and the commit itself drops to well under a millisecond in this model. The next section explains the third panel, under the chart.

Ask why each component rendered

Knowing that Recommendations is slow is half the answer. The other half is why it rendered. DevTools can record that too, but only if you ask before you record: open the Profiler's settings (the gear icon) and turn on Record why each component rendered while profiling. Then, when you select a component in a commit, the panel on the right shows a heading Why did this render? with one of these answers:

How to read the table: each row is one answer DevTools can give, what it means, and what to look at next.

For a function component, DevTools counts its Hooks in the order the component calls them. In ShopPage, Hook 1 is the useState for query on line 10, and Hook 2 the one for cartCount on line 11. So typing makes DevTools say Hook 1 changed for ShopPage, and Add says Hook 2 changed. When DevTools can read the names of your variables, it shows them beside the numbers.

Go back to the playground with plain Recommendations, type a letter, and click each bar in that commit:

• ShopPage: Hook 1 changed. Its own state changed, so it rendered.
• ProductList: Props changed: query, onAdd. The query really changed. onAdd did too, because line 16 makes a new arrow function every time ShopPage renders.
• CartBadge, Recommendations, and every Pick: The parent component rendered. Nothing they use changed.

That last answer is the one to look for. A render where nothing changed does no useful work: React calls the component, gets the same result, and puts nothing new on the page. For 15 slow picks, that's about 45 milliseconds of work for no change. The fix the playground's second version uses is memo: wrapped in memo, a component is skipped when its props are the same as last time. Here is the same shop, with only the last line of the Recommendations.jsx tab changed to export default memo(Recommendations);. Type mint quickly again:

1import { useState } from "react";2import ProductList from "./ProductList.jsx";3import Recommendations from "./Recommendations.jsx";4 5function CartBadge({ count }) {6  return <p>Cart: {count}</p>;7}8 9export default function ShopPage() {10  const [query, setQuery] = useState("");11  const [cartCount, setCartCount] = useState(0);12  return (13    <>14      <CartBadge count={cartCount} />15      <input value={query} onChange={(e) => setQuery(e.target.value)} placeholder="Search teas" />16      <ProductList query={query} onAdd={() => setCartCount(cartCount + 1)} />17      <Recommendations />18    </>19  );20}

The letters keep up now. App.jsx is the same as before; in the Recommendations.jsx tab, line 1 imports memo and line 25 exports memo(Recommendations). memo has a lesson of its own, memo, useMemo and useCallback, and so does The React Compiler, which adds the same skipping for you at build time. The next lesson shows fixes that change the structure instead, like moving the search state into a component of its own. Whichever fix you choose, the profile tells you where to put it, and a second profile tells you if it worked.

One more setting helps before you record anything, and When React re-renders showed where it is: in DevTools' general settings, turn on Highlight updates when components render. While you use the page, DevTools draws a short-lived outline around each component that renders. Typing in the plain shop, you'd see the picks light up on every key. Tick the same box in the playground to see it there.

Measure in code with the Profiler component

DevTools measures while you watch. React also lets your own code measure: wrap part of the tree in <Profiler>, a component built into React, and give it a function. React calls that function after every commit that renders anything inside it. Here the shop measures its two lists. Type a letter, then open the console under the result:

1import { Profiler, useState } from "react";2import ProductList from "./ProductList.jsx";3import Recommendations from "./Recommendations.jsx";4 5function logRender(id, phase, actualDuration, baseDuration) {6  console.log(`${id} ${phase}: actual ${actualDuration.toFixed(1)} ms, base ${baseDuration.toFixed(1)} ms`);7}8 9export default function ShopPage() {10  const [query, setQuery] = useState("");11  const [cartCount, setCartCount] = useState(0);12  return (13    <>14      <p>Cart: {cartCount}</p>15      <input value={query} onChange={(e) => setQuery(e.target.value)} placeholder="Search teas" />16      <Profiler id="ProductList" onRender={logRender}>17        <ProductList query={query} onAdd={() => setCartCount(cartCount + 1)} />18      </Profiler>19      <Profiler id="Recommendations" onRender={logRender}>20        <Recommendations />21      </Profiler>22    </>23  );24}

Line 1 imports Profiler from React. Lines 16 to 18 wrap ProductList in a <Profiler> with an id and an onRender function, and lines 19 to 21 do the same for Recommendations. Lines 5 to 7 are logRender: React calls it with what was rendered and how long it took, and it prints one line. After the page loads and you type one letter, the console shows something like this (your numbers will differ):

ProductList mount: actual 0.4 ms, base 0.2 ms
Recommendations mount: actual 92.1 ms, base 90.6 ms
ProductList update: actual 0.1 ms, base 0.1 ms
Recommendations update: actual 91.3 ms, base 91.3 ms

The first two lines come from the first render, and the next two from one key. The picks wait at least 45 ms, yet the log says about 90: in development, StrictMode calls each component twice, and the Profiler counts both calls. React passes onRender six values, in this order:

How to read the table: each row is one value React passes to onRender, in order.

actualDuration and baseDuration are the two worth comparing. The first is what this commit really cost. The second is what it would cost if every component inside rendered, added up from each one's last render. When they're about equal, as they are here, everything inside rendered. Now wrap the picks in memo: same App.jsx, and the Recommendations.jsx tab exports memo(Recommendations), as in the last section. Type a letter again:

1import { Profiler, useState } from "react";2import ProductList from "./ProductList.jsx";3import Recommendations from "./Recommendations.jsx";4 5function logRender(id, phase, actualDuration, baseDuration) {6  console.log(`${id} ${phase}: actual ${actualDuration.toFixed(1)} ms, base ${baseDuration.toFixed(1)} ms`);7}8 9export default function ShopPage() {10  const [query, setQuery] = useState("");11  const [cartCount, setCartCount] = useState(0);12  return (13    <>14      <p>Cart: {cartCount}</p>15      <input value={query} onChange={(e) => setQuery(e.target.value)} placeholder="Search teas" />16      <Profiler id="ProductList" onRender={logRender}>17        <ProductList query={query} onAdd={() => setCartCount(cartCount + 1)} />18      </Profiler>19      <Profiler id="Recommendations" onRender={logRender}>20        <Recommendations />21      </Profiler>22    </>23  );24}

Now each key logs something like Recommendations update: actual 0.0 ms, close to zero, while baseDuration stays at about 90. React still calls onRender, because the <Profiler> itself got new props from ShopPage, but nothing inside it rendered. A small actualDuration next to a large baseDuration is how you see, in numbers, that skipping works.

Three things to know before you add Profilers to an app:

• Production builds turn it off. Measuring has a small cost, so in a normal production build React never calls onRender. React ships a profiling build for that: a production build with measuring left on. You use it by importing react-dom/profiling instead of react-dom/client, usually with an alias in your bundler, shown below for Vite. Some frameworks have a setting that does it for you.
• Development numbers run slow. StrictMode's second call and React's extra checks make every component slower in development. Compare numbers with each other, before and after a change, not with a goal like "under 16 ms".
• Each Profiler costs a little. Wrap the parts you're asking about, not every component. Profilers can nest, and several can share one onRender; the id tells them apart.

// vite.config.js
import { defineConfig } from "vite";

export default defineConfig({
  resolve: {
    alias: {
      "react-dom/client": "react-dom/profiling",
    },
  },
});

Line 7 tells Vite: whenever code imports react-dom/client, use react-dom/profiling instead. Both have the same createRoot, so your main.jsx doesn't change. This is a build setting, so it runs in Node, not in the page, and has no result to show.

React's tracks in Chrome's Performance panel

React DevTools only sees React. Sometimes the time goes somewhere else: the browser working out the layout, painting, a network request, or another script. Chrome's own Performance panel records all of it on one timeline. The Measuring performance lesson shows how to record with it. In short: open the panel, press record, do the slow thing, and stop. The Main track then shows every piece of work the page's main thread did, and marks any task longer than 50 milliseconds as a long task.

Since React 19.2, React adds its own tracks to that timeline (the React 19.2 release post announced them, and React Performance tracks describes each one). They appear in development builds without any setup, and their names end in React's atom symbol:

• Scheduler shows React's work by priority, in rows: Blocking for urgent updates, like a key press, Transition for updates inside startTransition, Suspense for showing fallbacks and revealing content, and Idle for the lowest priority. Each update shows as its phases in order: Update (what started it), Render, Commit, and Remaining Effects (your useEffect code).
• Components shows which components rendered, as a flamegraph laid out over time, under the Render phase that rendered them. Effects that take 0.05 ms or more show too. Labels like Mount mark a part of the tree that just appeared. In development, clicking a component's entry shows which of its props changed.

Every live result on this page runs React 19.3.1 as a development build, so you can try it here in Chrome. Open the developer tools on this page, choose Performance, press record, type a few letters in the next result, and stop. Look for the Scheduler and Components tracks under the timeline.

1import { useEffect, useState } from "react";2import RenderCount from "./RenderCount.jsx";3 4const teas = ["Green tea", "Black tea", "Mint tea", "Chai"];5 6export default function TeaSearch() {7  const [query, setQuery] = useState("");8  const [matches, setMatches] = useState(teas);9 10  useEffect(() => {11    setMatches(teas.filter((tea) => tea.toLowerCase().includes(query.toLowerCase())));12  }, [query]);13 14  return (15    <>16      <input value={query} onChange={(e) => setQuery(e.target.value)} placeholder="Search teas" />17      <p>Matches: {matches.length} <RenderCount /></p>18      <ul>19        {matches.map((tea) => <li key={tea}>{tea}</li>)}20      </ul>21    </>22  );23}

Line 8 keeps matches in state, and the Effect on lines 10 to 12 works them out again after each new query. Line 17 shows a render counter from the RenderCount.jsx tab; it counts the renders React put on the page. Type m: the counter goes up by 2, not 1. The key renders with the old matches, the Effect runs, sets new matches, and the component renders a second time. In the Scheduler track, that second update is labelled Cascading Update: an update that started while React was still finishing the first one. React's documentation calls cascading updates out as a common cause of slow pages. Clicking the entry shows which component started it.

The fix is the one from You might not need an Effect: work out the matches while rendering. Type m here, and the counter goes up by 1:

1import { useState } from "react";2import RenderCount from "./RenderCount.jsx";3 4const teas = ["Green tea", "Black tea", "Mint tea", "Chai"];5 6export default function TeaSearch() {7  const [query, setQuery] = useState("");8  const matches = teas.filter((tea) => tea.toLowerCase().includes(query.toLowerCase()));9 10  return (11    <>12      <input value={query} onChange={(e) => setQuery(e.target.value)} placeholder="Search teas" />13      <p>Matches: {matches.length} <RenderCount /></p>14      <ul>15        {matches.map((tea) => <li key={tea}>{tea}</li>)}16      </ul>17    </>18  );19}

Line 8 filters the teas during the render, so each key is one render and one commit, and the Scheduler track shows no cascading update. In a production build these tracks are off. React's profiling build, from the last section, turns the Scheduler track back on, and the Components track lists the components inside a <Profiler> (or all of them while the React DevTools extension is installed).

A measure-first workflow

Each tool answers a different question. Put together, they make a short routine for any interaction that feels slow:

1. Pick one interaction and write it down: "typing in the search box", "opening the cart".
2. Make it realistic. Your computer is probably faster than your users'. In Chrome's Performance panel, set CPU to a 4x slowdown. For real numbers, use a production or profiling build; development numbers are only good for comparing before and after.
3. Record only that interaction in the Profiler, with "Record why each component rendered" on.
4. Find the slow commit and its widest bar, or the top of the ranked chart.
5. Ask why it rendered. "The parent component rendered" and props that change on every render are the usual answers.
6. Fix one thing, then record again and compare. If the numbers didn't move, undo the change.

Sometimes the slow part is one calculation, not a whole component. Then measure just that, with console.time and console.timeEnd. Type in the box and read the console:

1import { useState } from "react";2import { products } from "./products.js";3 4export default function ProductSearch() {5  const [query, setQuery] = useState("");6  console.time("filter products");7  const matches = products.filter((product) => product.name.includes(query));8  console.timeEnd("filter products");9  return (10    <>11      <input value={query} onChange={(e) => setQuery(e.target.value)} placeholder="Search 5,000 teas" />12      <p>{matches.length} matches</p>13    </>14  );15}

The products.js tab makes 5,000 products. Line 6 starts a timer named filter products, line 7 filters them, and line 8 stops the timer and prints how long it ran, like filter products: 0.400 ms. Each render prints a line, two per key in development. react.dev's rule of thumb: if the logged times add up to a millisecond or more for one interaction, the calculation may be worth skipping when its inputs haven't changed. Here filtering 5,000 short names takes well under that, so leave it alone.

How to read the table: each row is a question you might have, and the tool that answers it.

Keep the slowest commits from a real session

The DevTools Profiler shows your own session. To learn what's slow for real users, apps keep the numbers from onRender and send them to their server. This version keeps them in an array and prints the slowest three on request. Type a few letters, press Add a couple of times, then press the top button and read the table in the console:

1import { Profiler, useState } from "react";2import ProductList from "./ProductList.jsx";3import Recommendations from "./Recommendations.jsx";4 5const commits = [];6 7function saveCommit(id, phase, actualDuration) {8  commits.push({ id, phase, ms: Number(actualDuration.toFixed(1)) });9}10 11function printSlowest() {12  const slowest = [...commits].sort((a, b) => b.ms - a.ms).slice(0, 3);13  console.table(slowest);14}15 16export default function ShopPage() {17  const [query, setQuery] = useState("");18  const [cartCount, setCartCount] = useState(0);19  return (20    <>21      <button onClick={printSlowest}>Print the 3 slowest commits</button>22      <p>Cart: {cartCount}</p>23      <input value={query} onChange={(e) => setQuery(e.target.value)} placeholder="Search teas" />24      <Profiler id="ProductList" onRender={saveCommit}>25        <ProductList query={query} onAdd={() => setCartCount(cartCount + 1)} />26      </Profiler>27      <Profiler id="Recommendations" onRender={saveCommit}>28        <Recommendations />29      </Profiler>30    </>31  );32}

Line 5 is the array, outside the component, so rendering never resets it. saveCommit on lines 7 to 9 adds one row per Profiler per commit. It only stores the numbers: setting state from onRender would start another render after every render. printSlowest on lines 11 to 14 sorts a copy of the rows, slowest first, and prints three with console.table. The table's top rows all say Recommendations, the first one usually with mount. In a real app, you would use a profiling build and send rows like these with navigator.sendBeacon every so often, not after each commit.

Common mix-ups

• "The component that does the obvious work is the slow one." No. In the shop, the search is quick and the picks, which don't use the query at all, take almost all the time. Record before you change anything.
• "A wide bar in the flamegraph rendered in this commit." No. Width comes from the last render the component did. A gray bar didn't render in this commit, however wide it is.
• "A re-render always changes the page." No. When nothing a component uses changed, React calls it, gets the same result, and changes nothing on the page. The time is still spent.
• "'Why did this render?' shows up on its own." No. Turn on "Record why each component rendered while profiling" in the Profiler's settings before you record.
• "onRender runs in production too." No. A normal production build never calls it. Use the profiling build, react-dom/profiling, to measure there.
• "Development timings are what users get." No. StrictMode calls each component twice, and React runs extra checks, so development is slower. Compare before and after, and use a production or profiling build for real numbers.
• "You need an extra library to see React in Chrome's Performance panel." No. Since React 19.2, development builds add the Scheduler and Components tracks by themselves.

Practice exercises

The shop exercises use the same files as the lesson: four teas in the ProductList.jsx tab and 15 slow picks in the Recommendations.jsx tab. The first two use the playground in Record a profile in React DevTools. Change the code with Edit & run; the result updates as you type.

import { useState } from "react";
import ProductList from "./ProductList.jsx";
import Recommendations from "./Recommendations.jsx";

function CartBadge({ count }) {
  return <p>Cart: {count}</p>;
}

export default function ShopPage() {
  const [query, setQuery] = useState("");
  const [cartCount, setCartCount] = useState(0);
  return (
    <>
      <CartBadge count={cartCount} />
      <input value={query} onChange={(e) => setQuery(e.target.value)} placeholder="Search teas" />
      <ProductList query={query} onAdd={() => setCartCount(cartCount + 1)} />
      <Recommendations />
    </>
  );
}

1import { useState } from "react";2import ProductList from "./ProductList.jsx";3import Recommendations from "./Recommendations.jsx";4 5function CartBadge({ count }) {6  return <p>Cart: {count}</p>;7}8 9export default function ShopPage() {10  const [query, setQuery] = useState("");11  const [cartCount, setCartCount] = useState(0);12  return (13    <>14      <CartBadge count={cartCount} />15      <input value={query} onChange={(e) => setQuery(e.target.value)} placeholder="Search teas" />16      <ProductList query={query} onAdd={() => setCartCount(cartCount + 1)} />17      <Recommendations />18    </>19  );20}

import { useState } from "react";
import ProductList from "./ProductList.jsx";
import Recommendations from "./Recommendations.jsx";

function CartBadge({ count }) {
  return <p>Cart: {count}</p>;
}

export default function ShopPage() {
  const [query, setQuery] = useState("");
  const [cartCount, setCartCount] = useState(0);
  return (
    <>
      <CartBadge count={cartCount} />
      <input value={query} onChange={(e) => setQuery(e.target.value)} placeholder="Search teas" />
      <ProductList query={query} onAdd={() => setCartCount(cartCount + 1)} />
      <Recommendations />
    </>
  );
}

1import { useState } from "react";2import ProductList from "./ProductList.jsx";3import Recommendations from "./Recommendations.jsx";4 5function CartBadge({ count }) {6  return <p>Cart: {count}</p>;7}8 9export default function ShopPage() {10  const [query, setQuery] = useState("");11  const [cartCount, setCartCount] = useState(0);12  return (13    <>14      <CartBadge count={cartCount} />15      <input value={query} onChange={(e) => setQuery(e.target.value)} placeholder="Search teas" />16      <ProductList query={query} onAdd={() => setCartCount(cartCount + 1)} />17      <Recommendations />18    </>19  );20}

1import { useState } from "react";2import ProductList from "./ProductList.jsx";3 4export default function ShopPage() {5  const [query, setQuery] = useState("");6  const [cartCount, setCartCount] = useState(0);7  return (8    <>9      <p>Cart: {cartCount}</p>10      <input value={query} onChange={(e) => setQuery(e.target.value)} placeholder="Search teas" />11      <ProductList query={query} onAdd={() => setCartCount(cartCount + 1)} />12    </>13  );14}

1import { Profiler, useState } from "react";2import ProductList from "./ProductList.jsx";3 4function logRender(id, phase, actualDuration) {5  console.log(`${id} ${phase}: ${actualDuration.toFixed(1)} ms`);6}7 8export default function ShopPage() {9  const [query, setQuery] = useState("");10  const [cartCount, setCartCount] = useState(0);11  return (12    <>13      <p>Cart: {cartCount}</p>14      <input value={query} onChange={(e) => setQuery(e.target.value)} placeholder="Search teas" />15      <Profiler id="ProductList" onRender={logRender}>16        <ProductList query={query} onAdd={() => setCartCount(cartCount + 1)} />17      </Profiler>18    </>19  );20}

1import { useEffect, useState } from "react";2import RenderCount from "./RenderCount.jsx";3 4const teas = ["Green tea", "Black tea", "Mint tea", "Chai"];5 6export default function TeaSearch() {7  const [query, setQuery] = useState("");8  const [matches, setMatches] = useState(teas);9 10  useEffect(() => {11    setMatches(teas.filter((tea) => tea.toLowerCase().includes(query.toLowerCase())));12  }, [query]);13 14  return (15    <>16      <input value={query} onChange={(e) => setQuery(e.target.value)} placeholder="Search teas" />17      <p>Matches: {matches.length} <RenderCount /></p>18      <ul>19        {matches.map((tea) => <li key={tea}>{tea}</li>)}20      </ul>21    </>22  );23}

1import { useState } from "react";2import RenderCount from "./RenderCount.jsx";3 4const teas = ["Green tea", "Black tea", "Mint tea", "Chai"];5 6export default function TeaSearch() {7  const [query, setQuery] = useState("");8  const matches = teas.filter((tea) => tea.toLowerCase().includes(query.toLowerCase()));9 10  return (11    <>12      <input value={query} onChange={(e) => setQuery(e.target.value)} placeholder="Search teas" />13      <p>Matches: {matches.length} <RenderCount /></p>14      <ul>15        {matches.map((tea) => <li key={tea}>{tea}</li>)}16      </ul>17    </>18  );19}

1import { Profiler, useState } from "react";2import ProductList from "./ProductList.jsx";3import Recommendations from "./Recommendations.jsx";4 5function logRender(id, phase, actualDuration, baseDuration) {6  console.log(`${id} ${phase}: actual ${actualDuration.toFixed(1)} ms, base ${baseDuration.toFixed(1)} ms`);7}8 9export default function ShopPage() {10  const [query, setQuery] = useState("");11  const [cartCount, setCartCount] = useState(0);12  return (13    <>14      <p>Cart: {cartCount}</p>15      <input value={query} onChange={(e) => setQuery(e.target.value)} placeholder="Search teas" />16      <Profiler id="ProductList" onRender={logRender}>17        <ProductList query={query} onAdd={() => setCartCount(cartCount + 1)} />18      </Profiler>19      <Profiler id="Recommendations" onRender={logRender}>20        <Recommendations />21      </Profiler>22    </>23  );24}

1import { Profiler, useState } from "react";2import ProductList from "./ProductList.jsx";3import Recommendations from "./Recommendations.jsx";4 5function logRender(id, phase, actualDuration, baseDuration) {6  console.log(`${id} ${phase}: actual ${actualDuration.toFixed(1)} ms, base ${baseDuration.toFixed(1)} ms`);7}8 9export default function ShopPage() {10  const [query, setQuery] = useState("");11  const [cartCount, setCartCount] = useState(0);12  return (13    <>14      <p>Cart: {cartCount}</p>15      <input value={query} onChange={(e) => setQuery(e.target.value)} placeholder="Search teas" />16      <Profiler id="ProductList" onRender={logRender}>17        <ProductList query={query} onAdd={() => setCartCount(cartCount + 1)} />18      </Profiler>19      <Profiler id="Recommendations" onRender={logRender}>20        <Recommendations />21      </Profiler>22    </>23  );24}

1import { Profiler, useState } from "react";2import ProductList from "./ProductList.jsx";3import Recommendations from "./Recommendations.jsx";4 5let slowest = null;6 7function saveCommit(id, phase, actualDuration) {8  // Keep this commit if it's slower than the slowest one so far.9}10 11export default function ShopPage() {12  const [query, setQuery] = useState("");13  return (14    <>15      <button onClick={() => console.log(slowest)}>Print the slowest commit</button>16      <input value={query} onChange={(e) => setQuery(e.target.value)} placeholder="Search teas" />17      <Profiler id="ProductList" onRender={saveCommit}>18        <ProductList query={query} onAdd={() => {}} />19      </Profiler>20      <Profiler id="Recommendations" onRender={saveCommit}>21        <Recommendations />22      </Profiler>23    </>24  );25}

1import { Profiler, useState } from "react";2import ProductList from "./ProductList.jsx";3import Recommendations from "./Recommendations.jsx";4 5let slowest = null;6 7function saveCommit(id, phase, actualDuration) {8  if (slowest === null || actualDuration > slowest.ms) {9    slowest = { id, phase, ms: Number(actualDuration.toFixed(1)) };10  }11}12 13export default function ShopPage() {14  const [query, setQuery] = useState("");15  return (16    <>17      <button onClick={() => console.log(slowest)}>Print the slowest commit</button>18      <input value={query} onChange={(e) => setQuery(e.target.value)} placeholder="Search teas" />19      <Profiler id="ProductList" onRender={saveCommit}>20        <ProductList query={query} onAdd={() => {}} />21      </Profiler>22      <Profiler id="Recommendations" onRender={saveCommit}>23        <Recommendations />24      </Profiler>25    </>26  );27}

Check your understanding

For each question, picture the commit: which components rendered in it, how long they took, and why.

Key takeaways

• Measure before you change anything: record the slow interaction, find what took the time, fix one thing, record again.
• The DevTools Profiler shows one commit at a time. In the flamegraph, width is the last render's time with children, and gray means it didn't render. The ranked chart sorts by each component's own time.
• Turn on "Record why each component rendered". "The parent component rendered" marks a render that changed nothing and can usually be skipped.
• <Profiler id onRender> measures in code. Compare actualDuration with baseDuration to see skipping work. Production builds turn it off; the profiling build turns it back on.
• Since React 19.2, Chrome's Performance panel shows React's Scheduler and Components tracks next to layout, paint, and network, including cascading updates.
• Development numbers are slower than real ones. Use them to compare, and a production or profiling build for real timings.

Coming next: Performance patterns. It shows the fixes a profile most often points to: moving state down, passing content as children, rendering only the rows on screen, and loading code only when it's needed.