Using the React Profiler — Finding Real Bottlenecks in Real Apps

---

Hey everyone, Richa here! 👋

Day 25. Last day of Week 5.

And today we wrap up the performance week with the tool that ties everything together.

The React Profiler.

Here's the thing — everything we've covered this week (code splitting, virtualisation, bundle optimisation, memoisation on Day 5) has one thing in common: you should only apply them where there's an actual, measurable problem.

The React Profiler is how you find those problems. It shows you exactly which components are rendering, why they're rendering, and how long each render takes.

Without it, you're guessing. With it, you're diagnosing.

---

Two profilers — know both

React DevTools Profiler — the browser extension, for runtime render profiling

The <Profiler> API — built into React, for measuring programmatically

We'll cover both. Start with the DevTools one — it's what you'll use 90% of the time.

---

React DevTools Profiler — getting started

Install the React DevTools browser extension (Chrome or Firefox). It adds two tabs to DevTools: Components and Profiler.

The Profiler tab workflow:

1. Open DevTools → Profiler tab

2. Click the Record button (circle)

3. Interact with your app — navigate, click, type

4. Click Stop (square)

5. Inspect the flame graph

The flame graph shows every render that happened during the recording — which component rendered, how long it took, and what triggered it.

---

Reading the flame graph

App (0.1ms)
  └── Layout (0.2ms)
        ├── Navbar (0.1ms)
        ├── Sidebar (0.3ms)
        └── ProductsPage (12.4ms) ← this is slow
              ├── ProductFilters (0.4ms)
              └── ProductGrid (11.8ms) ← almost all the time is here
                    ├── ProductCard (0.2ms)
                    ├── ProductCard (0.2ms)
                    ├── ProductCard (0.2ms)
                    ... × 200 cards

What the colours mean:

• Grey — component didn't re-render this cycle

• Blue/teal — rendered, reasonable time

• Yellow/orange — rendered, slower

• Red — rendered, slow — investigate

What to look for:

• Components that are grey when they should be (not re-rendering unnecessarily) ✅

• Components that are coloured every time even when nothing changed ❌

• Components with unexpectedly long render times

• Components that render many times for one user action

---

Finding unnecessary re-renders

This is the most common use case. You suspect a component is re-rendering too often. The Profiler tells you exactly when and why.

After recording, click on any rendered component in the flame graph. The right panel shows:

Why did this render?
  ● Props changed
      ○ onAddToCart: [function] → [function]  ← different function reference!

This tells you: ProductCard re-rendered because onAddToCart was a new function reference every time the parent rendered.

The fix from Day 5: useCallback on the function.

// ❌ Before — new function reference every render
function ProductGrid({ products }: { products: Product[] }) {
  const addToCart = useCartStore(state => state.addItem);

  return products.map(p => (
    <ProductCard
      key={p.id}
      product={p}
      onAddToCart={() => addToCart(p)} // ← new arrow function every render
    />
  ));
}

// ✅ After — stable function reference
function ProductGrid({ products }: { products: Product[] }) {
  const addToCart = useCartStore(state => state.addItem);

  const handleAddToCart = useCallback((product: Product) => {
    addToCart(product);
  }, [addToCart]);

  return products.map(p => (
    <MemoizedProductCard
      key={p.id}
      product={p}
      onAddToCart={handleAddToCart}
    />
  ));
}

const MemoizedProductCard = React.memo(ProductCard);

Profile again — the ProductCard components should now be grey (not re-rendering) when the parent renders for unrelated reasons.

---

The <Profiler> API — measuring in code

For more targeted measurement — especially when you want numbers logged to the console or sent to monitoring:

import { Profiler, type ProfilerOnRenderCallback } from 'react';

const onRenderCallback: ProfilerOnRenderCallback = (
  id,           // the "id" prop of the Profiler
  phase,        // "mount" or "update"
  actualDuration,   // time spent rendering the committed update
  baseDuration,     // estimated time to render entire subtree without memoisation
  startTime,    // when React began rendering the update
  commitTime,   // when React committed the update
) => {
  // Log slow renders
  if (actualDuration > 16) { // 16ms = 1 frame at 60fps
    console.warn(`Slow render: \({id} took \){actualDuration.toFixed(2)}ms (${phase})`);
  }

  // Or send to monitoring (Datadog, Sentry, custom analytics)
  if (actualDuration > 50) {
    analytics.track('slow_render', {
      component: id,
      phase,
      duration: actualDuration,
    });
  }
};

function ProductsPage() {
  return (
    <Profiler id="ProductsPage" onRender={onRenderCallback}>
      <ProductFilters />
      <ProductGrid />
    </Profiler>
  );
}

actualDuration > 16ms means the component is slower than one frame at 60fps — a good threshold for "investigate this."

---

A complete profiling workflow — finding and fixing a real issue

Here's how I approach a performance complaint in production:

Step 1 — Reproduce the issue

User says: "the dashboard feels slow when I type in the search box."

Open DevTools → Profiler. Start recording. Type in the search box. Stop.

Step 2 — Read the flame graph

DashboardPage (0.3ms)
  SearchBar (0.1ms)           ← the component being typed in
  StatsSummary (4.2ms)        ← why is this re-rendering?
  UserActivityChart (8.7ms)   ← and this?
  RecentOrdersTable (11.3ms)  ← and this!

Three heavy components re-rendering on every keystroke in the search bar.

Step 3 — Check why they're re-rendering

Click StatsSummary in the Profiler. "Why did this render?"

Why did this render?
  ● Parent component rendered

DashboardPage re-renders when the search state changes → all its children re-render.

Step 4 — Apply the fix

// Before — everything re-renders when searchQuery changes
function DashboardPage() {
  const [searchQuery, setSearchQuery] = useState('');

  return (
    <div>
      <SearchBar value={searchQuery} onChange={setSearchQuery} />
      <StatsSummary />        {/* re-renders on every keystroke */}
      <UserActivityChart />   {/* re-renders on every keystroke */}
      <RecentOrdersTable />   {/* re-renders on every keystroke */}
    </div>
  );
}

// After — heavy components memoised, only re-render if their props change
const MemoStatsSummary = React.memo(StatsSummary);
const MemoUserActivityChart = React.memo(UserActivityChart);
const MemoRecentOrdersTable = React.memo(RecentOrdersTable);

function DashboardPage() {
  const [searchQuery, setSearchQuery] = useState('');

  return (
    <div>
      <SearchBar value={searchQuery} onChange={setSearchQuery} />
      <MemoStatsSummary />        {/* only re-renders if its own props change */}
      <MemoUserActivityChart />
      <MemoRecentOrdersTable />
    </div>
  );
}

Step 5 — Profile again to verify

Record. Type in the search box. Stop.

DashboardPage (0.3ms)
  SearchBar (0.1ms)           ← still updating (correct)
  StatsSummary (grey)         ← not re-rendering ✅
  UserActivityChart (grey)    ← not re-rendering ✅
  RecentOrdersTable (grey)    ← not re-rendering ✅

Fixed. And we can see it in the Profiler — not just assume it.

---

Performance marks — custom timing

For more precise measurement of specific operations:

// Mark the start and end of a user interaction
function handleSearch(query: string) {
  performance.mark('search-start');

  setSearchQuery(query);

  // After React renders
  requestAnimationFrame(() => {
    performance.mark('search-end');
    performance.measure('search-render', 'search-start', 'search-end');

    const measure = performance.getEntriesByName('search-render')[0];
    console.log(`Search render: ${measure.duration.toFixed(2)}ms`);
  });
}

You can see these custom marks in DevTools → Performance tab alongside React's own renders.

---

The golden rules of profiling

Rule 1 — Always measure before optimising

Don't add React.memo or useMemo because you think it might help. Profile first. Confirm the problem. Then apply the fix. Then profile again to confirm the fix worked.

Rule 2 — Profile on realistic hardware

Chrome DevTools → Performance tab has a CPU throttle setting. Set it to 4x or 6x slowdown to simulate mid-range Android performance. A fast MacBook Pro hides performance problems that real users face.

Rule 3 — Profile in production mode

React's development mode has extra overhead (warnings, checks, etc.). Profile your production build for accurate numbers:

npm run build
npm run preview  # serves the production build locally

Rule 4 — Fix the worst first

The Profiler shows everything. Start with the slowest component or most frequent unnecessary render. Fix that. Profile again. Repeat.

Rule 5 — Grey is good

In the flame graph — grey means "didn't render." More grey = fewer unnecessary renders. After a round of optimisation, you want to see much more grey than before.

---

Week 5 wrap-up

This week we covered:

• Day 21 — Rendering patterns: CSR, SSR, SSG, ISR — the decision framework

• Day 22 — Code splitting: React.lazy, Suspense, dynamic imports

• Day 23 — List virtualisation: TanStack Virtual for 5,000+ row lists

• Day 24 — Bundle optimisation: tree shaking, lighter libraries, the visualiser

• Day 25 — React Profiler: finding and fixing real render bottlenecks

Next week: System Design Interview Patterns — the scenarios they actually ask at senior/staff interviews. Real problems, real solutions.

See you Monday for Day 26 — System design: Design a social media feed (infinite scroll, caching).

---

← Day 24 — Bundle Optimisation → Day 26 — Design a Social Media Feed

---

Part of the React System Design Series — 40 days, one topic per day.