React Developer Tools

March 20, 20254 min read

Before optimising anything, you need to see what's actually happening. React DevTools gives you a live view of your component tree, what's rendering, and why.

Installation

Install from the Chrome Web Store (or Firefox Add-ons). Once installed, pin the extension — when the icon turns orange, the current page is running React in development mode. Grey means either no React or a production build.

That colour matters: if you ever see an app running slower than expected, check if someone accidentally shipped their dev build. It happens.

The Components Tab

The Components tab shows your component tree as React sees it — not the DOM, but the actual component hierarchy.

What it's useful for:

  • Find the file — hover over any component and it shows the source file path. The fastest way to find which file to edit for a given piece of UI.
  • Inspect props and hooks — click any component to see its current props, state, and context values in the right panel.
  • Trace who rendered it — the panel shows what triggered the last render.

Not performance-critical on its own, but invaluable when you need to understand the tree.

Highlight Updates When Components Render

This is the most useful performance feature in DevTools. Find it in the settings gear (⚙) → "Highlight updates when components render".

Once enabled, every component that re-renders gets a coloured flash — blue for infrequent renders, yellow/red for frequent ones. You don't need to open the Profiler to see the problem; it's right there as you use the app.

Use this to answer: is anything re-rendering that shouldn't be?

Type into an input field with this enabled. If everything on the page flashes on every keystroke, the state is probably living too high in the tree.

Note: this feature only runs in development mode and only when DevTools is open. You're not shipping this overhead to users.

The Profiler Tab

The Profiler records exactly what rendered during an interaction and how long each component took.

Basic workflow:

  1. Click Record
  2. Interact with the app (type, click, navigate)
  3. Click Stop
  4. Read the flame graph

The flame graph shows each commit (update cycle). Click a bar to see which components rendered in that commit and their durations. Taller bars = more render time.

"Record why each component rendered"

Enable this in Profiler settings for extra signal: it logs whether each component re-rendered because of a state change, prop change, or parent re-render.

Warning: recording why things rendered adds overhead. The timings you see with this on are bigger than real-world numbers. Don't use them to benchmark performance — use them to diagnose the cause.

Development vs Production Performance

Everything is slower in development mode. React does extra work:

  • Tracking which components rendered and why
  • Double-invoking renders for Strict Mode
  • Keeping component names readable in the DevTools
  • Running additional validation warnings

Never benchmark in development mode. If you pull a coworker's PR, run it in dev, and say "this is slow" — you're wrong. Benchmark against a production build.

If you want closer-to-production profiling numbers without a full deploy, you can swap react-dom for react-dom/profiling in your build config (Vite resolve aliases, Webpack aliases). The numbers are more realistic than dev but still have some profiling overhead.

Simulating Real-World Conditions

Your development machine is not your user's machine. Two tools help close that gap:

Network throttling (DevTools → Network → throttle dropdown) — simulates slow 3G, fast 3G, etc. Only active when DevTools is open. Turn it off before you call your ISP wondering why everything is broken.

CPU throttling (DevTools → Performance → CPU slowdown) — simulates a 4x or 6x slower device. This is the most eye-opening one. If your app feels fine on your M3 MacBook but users report lag, CPU throttle to 4x and you'll feel what they feel.

The act of measuring always adds some overhead. That's fine — you're diagnosing, not benchmarking.

The Methodology

  1. Open DevTools, enable "Highlight updates when components render"
  2. Use the app normally and watch for unexpected flashes
  3. If something flashes that shouldn't, open Profiler and record the interaction
  4. Find the component with the most unexpected re-renders
  5. Check why it rendered (props? parent? context?)
  6. Fix the root cause — usually state living too high

Measure first. The tools will point you to the problem. Don't start optimising before they do.

Practice

0/5 done