← Back to React Course | Chapter 14: Performance & Production Deployment | Lesson 4 of 13

Using the React Profiler

The React Profiler is like a stopwatch and clipboard for your app, timing exactly how long each component takes to render so you know where to actually focus your effort.

In this page:

  1. Recording a Profiling Session
  2. Reading the Flame Graph
  3. Profiling with a Production-Like Build

Recording a Profiling Session

The Profiler tab in React DevTools lets you click record, perform some interaction in your app (like typing in a search box or clicking a button), then stop recording to see exactly which components rendered, how long each took, and why.

Note: Record a focused, specific interaction (not just random clicking around) so the resulting data is easy to interpret.

Warning: The Profiler is a browser extension feature — it can't be demonstrated running live inside this code preview, only described here.

Reading the Flame Graph

The Profiler's flame graph shows each component as a colored bar — wider/darker bars represent components that took longer to render. Clicking a specific render (a numbered bar at the top) lets you see exactly which components rendered during that particular update and why.

Note: Look for unexpectedly wide bars for components you didn't expect to be doing much work — that's often where a real optimization opportunity hides.

Warning: A component appearing in the flame graph doesn't automatically mean it's a problem — check both how OFTEN it renders and how LONG each render actually takes.

Profiling with a Production-Like Build

React's development build includes extra warnings and checks that make it noticeably slower than a real production build. For accurate, real-world performance numbers, profile against a production build (or React's profiling build), not the default development server.

Note: Most bundlers (Vite, webpack via Create React App) offer a way to build a profiling-enabled production bundle specifically for this purpose.

Warning: Development-mode timings can be significantly slower than production, potentially making you optimize for a problem that doesn't actually exist in the real, deployed app.

Example: Building and Previewing Before Profiling

bash 
$ npm run build
vite v5.0.0 building for production...
✓ 34 modules transformed.

$ npm run preview
  ➜  Local:   http://localhost:4173/
# open React DevTools Profiler against this URL, not the dev server

⚠️ Run this command in your terminal.

Common Mistakes
  1. Guessing which components are slow instead of actually recording and reading a Profiler session.
  2. Profiling in development mode and assuming those exact timings apply to production (development builds include extra checks that slow things down).
  3. Not using the 'Why did this render?' feature/flame graph to understand the ACTUAL cause of a re-render before trying to fix it.
Chapter Summary
  • The React DevTools Profiler tab records render timings for every component during an interaction.
  • The flame graph visualizes which components took the most time, and how often they re-rendered.
  • Profiling should happen with a production-like build when checking actual real-world performance numbers.
  • Use the Profiler's data to target specific slow components, rather than guessing where to optimize.
Browser Support

React DevTools extension supports the Profiler for React 16.5+.

🔒

Chapter Quiz — Complete all 13 topics to unlock

0/13 topics done

Complete these topics first:

← Previous Lesson Avoiding Unnecessary Re-renders Next Lesson → Analyzing Bundle Size

Login to run this code

C/C++/Java/PHP execution requires a free account. Your code is saved — you'll land right back in the editor after logging in.