This whole module has leaned on a rule that, until now, has only ever been stated without being fully backed up: don't optimize what you haven't measured. There's been talk of renders that shouldn't happen, of props changing identity, of 40 ms computations and 271 KB bundles, and every one of those claims was really a promise: "this can be checked." This lesson is where that promise gets cashed in. The React DevTools Profiler records what happens inside React during an interaction and answers, with precision, the three questions that turn a suspicion into a diagnosis: which components rendered, how long each one took, and — the most valuable one — why. With that last answer, "I think the list is over-rendering" stops being a hunch and becomes "BikeCard rendered 2,000 times in a 214 ms commit because the onBook prop changed." The difference between those two sentences is the difference between touching code blindly and fixing an actual problem. By the end of the lesson you'll walk through CicloUrbano's complete case — measure, diagnose, fix, measure again — and you'll also know the hardest part of all: when to stop.

1. Installing React DevTools and what each tab gives you
2. Why you measure in a production build
3. Anatomy of the Profiler: recording an interaction
4. Commits, the flame graph, and the ranked chart
5. The numbers: render duration, self time, and render count
6. Why this repainted: the four causes
7. Highlighting updates in the browser
8. Case study: CicloUrbano's search box, before and after
9. The <Profiler> API in code
10. Complements outside React
11. When to stop optimizing

React DevTools is an official extension available for Chrome, Edge, and Firefox, and also as a standalone app (npx react-devtools) for debugging React Native or pages served outside a desktop browser.

Once installed, opening the browser's dev tools on a page running React shows two new tabs:

The React icon in the browser toolbar also gives you instant information without opening anything: if it's in color, the page uses React; and its shade tells you whether it's in development mode (red) or production (blue). That detail matters more than it looks, and the next section explains why.

Two settings in the Components tab worth knowing before profiling:

• Highlight updates when components render: draws a box around every component that renders. It's the fastest visual diagnostic there is (section 7).
• The ✨ Memo ✨ badge next to a component's name: it means the React Compiler has optimized it (08-03). If your critical component doesn't have it in a compiled project, the compiler skipped it.

This is the module's most-ignored instruction, and the one that invalidates the most measurements.

What distorts development mode, point by point:

The practical consequences:

• Absolute times from development mode are useless. A 214 ms commit in development might be 60 ms in production.
• Proportions do hold up. If BikeCard accounts for 80% of the commit in development, it'll still be the problem in production. That's why developing with the Profiler open is useful for locating issues, even though the final figures have to come from a build.
• Conclusions of the "it repainted N times" kind are valid in development, once you subtract StrictMode's effect.

One important technical detail: React's standard production build strips out the Profiler's instrumentation. To profile in production you have to build with profiling enabled:

keep_fnames deserves a comment: without it, minification renames functions and the Profiler shows t, e, n instead of BikeCard. With it, the bundle weighs a bit more, but the flame graph is readable. It's a measurement configuration, not a deployment one.

Recommended flow: locate in development (fast, with hot reload) and confirm and quantify in a profiling-enabled production build. Never close out an issue with development figures.

The recording cycle has five steps, and the second one is the one almost everybody skips:

1. Open the Profiler tab.
2. Prepare the initial state: navigate to the screen, wait for the data to load, let the interface settle. If you record the initial load together with the interaction, you won't be able to tell them apart.
3. Click the record button (blue circle).
4. Do one single thing: type five letters into the search box. Nothing else.
5. Stop the recording and analyze it.

Before recording, turn on these two settings in the Profiler's gear icon ⚙:

A principle that saves a lot of time: one recording, one interaction. Recording "I open the app, navigate, filter, type, and book" produces a log that's impossible to interpret. Keep recordings short, with a specific hypothesis.

Across the top you'll see a series of bars: each one is a commit — one instance of React applying changes to the DOM. Remember the cycle from 01-05: render → diff → commit. The Profiler measures from when React starts rendering to when it finishes applying the changes.

• The height of each bar is that commit's duration.
• The color runs from gray (fast) to yellow (slow). Yellow grabs your attention, but the real criterion is the milliseconds.
• Clicking a bar lets you examine that specific commit.

Five keystrokes should produce roughly five commits. If you see fifteen, you already have a data point: something is triggering cascading renders.

It's the default view, and it shows that commit's component tree.

• Width = time that component and its descendants took to render.
• Vertical position = depth in the tree: children below parents.
• Color: gray = didn't render in this commit; yellow to green = it rendered, with yellow indicating more time.

What to look for: wide, yellow bars, and above all colored bars where you expected gray. A component that shouldn't have rendered showing up in color is exactly the kind of finding you're after.

The same information sorted from highest to lowest time, without the tree structure. It's the view for answering "what's costing me time?" in two seconds. The flame graph answers "why is it happening?"

Selecting a component in either view shows its numbers in the side panel. These are the ones worth knowing how to read:

The distinction between the first two is the one that prevents the most diagnostic mistakes:

CataloguePage looks like the culprit at 214 ms, but its self time is 0.8 ms: it's barely doing anything. The cost is spread across 2,000 cards at 0.1 ms each. The problem isn't that one card is expensive; it's that there are 2,000 of them. That distinction decides the fix: optimizing the inside of BikeCard won't help here — what helps is preventing them from running (memo) or from existing at all (paginate, virtualize).

And the opposite case, with the same total:

Here it's real: a single component consumes 178 ms on its own. There's a heavy computation inside, and the tool for that is useMemo or a better algorithm.

With "Record why each component rendered" turned on, the side panel adds a "Why did this render?" section, and that's where the tool's differential value lives. The causes it can report are exactly 08-01's four:

The first one is the most valuable of all, because it names the culprit prop. Without the Profiler, figuring out which of seven props changed identity means instrumenting the component by hand (as in 08-02). With it, it's one line of text.

And the strategic way to read the table, the one that turns the entire module into a procedure:

Before recording anything, there's a five-second diagnostic. In the Components tab, gear icon ⚙ → General → Highlight updates when components render.

From that point on, every component that renders gets surrounded by a colored box for an instant:

Type a letter into BikeSearch and watch. If the whole screen lights up — header, footer, fleet summary, all 2,000 cards — you've located the problem without recording anything. If only the text field flickers, there's nothing to investigate there.

It's the ideal tool for three things: a quick check before a serious profiling session, confirming at a glance whether a freshly added memo actually worked, and catching continuous renders caused by a badly written effect (a component that flickers without anyone touching it is a render loop).

Turn it off when measuring times: drawing the boxes costs work and pollutes the numbers.

This is the complete walkthrough, with the 2,000-bike catalogue, a profiling-enabled production build, and the CPU throttled 4× to simulate a mid-range phone.

Reported symptom: "when typing in the search box, letters take a while to appear." Interaction to measure: typing "electr" (6 keystrokes) into BikeSearch. Budget (08-01): INP < 200 ms; commits < 16 ms.

Recording, with the commit timeline:

Six commits at ~220 ms each. The 16 ms budget is blown fourteen times over. The feeling that "the letters are slow" is confirmed with numbers: every keystroke blocks the main thread for more than a fifth of a second.

Ranked view for commit 3:

Flamegraph view: 95% of the width is the BikeCard row.

Pick any BikeCard and read the side panel:

Complete diagnosis, and notice there's no guesswork left in it:

1. BikeCard isn't memoized (08-02), so it reruns on every render of its parent.
2. Even if it were, onSelect and onBook are arrow functions created inline in BikeList: memo would fail regardless (08-03).
3. Each card costs little (0.11 ms), but there are 2,000 of them.
4. On top of that, all the filtering happens synchronously and urgently, in the same update as the keystroke.

They're applied, and this matters, one at a time, measuring between each step:

4.1 — memo on BikeCard (08-02), also pulling the Intl.NumberFormat out of the component.

Measurement: no change (≈220 ms). And that's a result, not a failure: it confirms point 2 of the diagnosis. A memo with unstable props saves nothing.

4.2 — useCallback in BikeList (08-03).

Measurement: commits drop to ~34 ms. And in the side panel for any card, the message has changed to what we were after:

Only the cards entering or leaving the filter render at all. 84% of the cost is gone with two hooks, but only because the memo from the previous step was already in place: neither one on its own would have helped.

4.3 — useDeferredValue in CataloguePage (08-03), so filtering stops competing with typing.

Measurement: now there are two kinds of commit per keystroke — an urgent one at ~2 ms that only updates the field, and a deferred, interruptible one at ~30 ms for the list — and during fast typing, several of the deferred ones get abandoned before they finish. The field responds instantly.

The budget is met with room to spare. There's still ~30 ms left in the deferred commits, and it could be attacked by virtualizing the list (08-01). But: they're deferred, they're interruptible, they don't block typing, and the user no longer perceives any delay. Virtualizing would add a dependency, complicate accessibility, and break Ctrl+F, in exchange for an improvement nobody would notice.

Decision: stop here. Document the numbers in PERFORMANCE.md and move on. That decision is as much a part of the craft as the three fixes before it.

The extension measures while you're watching. To measure automatically — in performance tests, in continuous integration, or in production with real users — React offers a component:

The onRender function receives six arguments:

The key pair is the third and fourth. baseDuration is what it would cost to render the whole subtree with no memo or useMemo at all; actualDuration is what it actually cost. The difference is, literally, what your memoization is saving:

Details worth knowing before using it:

A very practical use in automated tests: log actualDuration to a file during an end-to-end test and fail the build if it exceeds a threshold. That's how a performance budget defends itself, without depending on someone remembering to measure. That kind of automated check is, precisely, the territory of Module 9.

The Profiler measures React's work, and React's work is only part of the total. These are the tools that cover the rest, mentioned so you know when to switch instruments:

The rule for choosing: if the Profiler says React consumes little time and the app still feels slow, the problem isn't React's. It'll be in the network, the images, the CSS, the layout, or a third-party library, and the browser's Performance tab is where you'll see it.

About web-vitals, one thing is worth insisting on: your laptop with localhost isn't a representative sample of anything. Measuring in production with real users reveals distributions — the 75th percentile of INP on Android phones, for instance — that no local measurement shows. This lesson doesn't go into it, but it's the natural destination for everything learned here.

It's the question that closes out the module, and the one taught the least. There are four clear signals to stop:

1. The budget is met. If you set INP < 200 ms and you're at 35 ms, you're done. A budget that doesn't stop the work once it's met was never a budget.

2. The improvement is no longer perceptible. There's a perceptual threshold: below ~100 ms a response feels instantaneous. Going from 40 ms to 25 ms is a 37% improvement on a spreadsheet and zero improvement for the user.

3. The readability cost outweighs the benefit. A component with four useMemos, three useCallbacks, and a custom comparator, to save 3 ms, is a component the next developer — or you, six months from now — will break the moment they touch it. That risk has a real cost.

4. There's a bigger problem somewhere else. If the app takes 3 s for the first paint, polishing a 20 ms commit further is putting effort in the wrong place. Go back to step 1 of 08-01's workflow and pick the biggest bottleneck, not the most entertaining one.

And the signal that you need to backtrack: if an optimization didn't produce a measurable improvement, revert it. Its complexity and memory cost is still there even if the benefit isn't. That discipline is what keeps a project from filling up with decorative memoization over the years.

Measuring in development mode and trusting the numbers. StrictMode doubles renders and warnings add cost. Locate in development; quantify in a profiling-enabled production build.

Recording too much. A recording with five different interactions is unreadable. One recording, one hypothesis.

Profiling without "Record why each component rendered". That's giving up half the tool: without the cause, you have timings but no diagnosis.

Confusing "render duration" with "self time". The first includes descendants. Blaming a parent with a 214 ms duration and 0.8 ms of self time is starting to optimize the wrong spot.

Chasing the number of rendered components. 2,000 renders at 0.01 ms matter less than one at 180 ms. The metric is time.

Forgetting keep_fnames when building for profiling. A flame graph full of t, e, and n is useless.

Leaving <Profiler> wrapping the whole app in production. It adds cost on every render. Wrap specific zones, and only while you need it.

Tip: save your recordings. The Profiler lets you export a profile to JSON and import it later. Keeping the "before" alongside the "after" turns an improvement into proof, and it's excellent material for a code review.

Tip: always throttle the CPU 4×. It's the difference between optimizing for your laptop and optimizing for your users.

Tip: write the numbers into the repo. A PERFORMANCE.md with the interaction measured, the date, the before and the after turns this module's work into something that outlives whoever did it.

Tip: profile even when everything's fine. Periodic measurement catches regressions while they're still small. Finding that a commit went from 12 ms to 40 ms in the last week is much easier than investigating why the app "feels slow" six months later.

Exercise 1. Interpret this recording of CicloUrbano's StationDetailPage, taken in a production build when clicking the "Incidents" tab. Say what the problem is, what is not the problem, and which technique from which lesson you'd apply.

Exercise 2. After applying memo to StationCard in StationsPage, the new recording shows this. Explain why the memo didn't help, what specific information tells you that, and how you'd fix it.

Exercise 3. Write a <Profiler> wrapper that logs the worst commit of each measured zone (id) to sessionStorage, storing duration, phase, and timestamp, and that warns via the console when a zone exceeds 16 ms two times in a row. Explain where you'd place it in CicloUrbano and why not at the root.

Solution 1. The problem: IncidentsTab consumes 168.9 ms of self time. It isn't a problem of how many components there are — only 63 in the whole commit — but of a single component doing heavy work inside its render: it's probably sorting, grouping, or formatting the incidents, quite possibly with a find inside a map, or an Intl instance created per element.

What is NOT the problem:

• It's not StationCard: 6.4 ms of duration but 0.4 ms of its own. Its cost belongs to its children.
• It's not the number of renders: 63 components is a perfectly healthy figure.
• It's not "The parent component rendered", even though that's the cause listed. The parent rendering is normal when switching tabs; wrapping IncidentsTab in memo wouldn't save anything, because this render had to happen: the user just clicked the tab.

Technique to apply: useMemo over the heavy computation (08-03), measuring beforehand with console.time to confirm it's actually expensive. And before that, review the algorithm: a Map index instead of linear searches, and a reused Intl.Collator, usually cut the cost more than memoization does. If the first render is still heavy after that, the next option is to keep the computation off the client entirely (useQuery's select, or the server directly).

Solution 2. Why it didn't help: the line Props changed: (freeDocks, onOpen, style) says it literally. Three props change identity on every render of the parent, so memo's shallow comparison always fails and the component runs anyway, with the comparison itself as added cost.

What information tells you that: the "Why did this render?" section with the list of props. Without it you'd have to instrument the component by hand with a tracing comparator (08-02).

How to fix it, prop by prop:

• onOpen: an inline arrow function. Stabilize it with useCallback in the parent, with [navigate] or [dispatch] as the dependency (08-03).
• style: an object literal, almost certainly a style={{ … }}. The best fix isn't to memoize it, but to eliminate it: move it to a CSS Modules class, the project's convention.
• freeDocks: if it's a number, the by-value comparison should succeed. Its showing up as changed means it's genuinely changing — maybe it's recalculated with a filter that returns a different value — or that it isn't a primitive. You'd need to inspect the value in the Components tab. If the data really does change, that render is correct and there's nothing to fix.

And the final check, the one that closes the loop: record again. The panel should now say Did not render for the cards whose data hasn't changed. If it doesn't, the fix hasn't worked and it's back to diagnosis.

Solution 3.

Where to place it, and why not at the root:

• You wrap zones with their own meaning — the catalogue, the station detail page, the workshop panel — because the id is what lets you attribute a problem to a specific screen. A single <Profiler id="app"> would give a global number that points at nothing.
• Not at the root, for three reasons: onRender fires on every render of the entire subtree, and at the root that's every render in the app (measurable added cost); the aggregated duration mixes work from independent zones and loses all diagnostic power; and the 16 ms threshold stops making sense once what's being measured is "the whole app" instead of one specific interaction.
• The warning after two commits in a row avoids the noise of isolated spikes — an initial load, a Query revalidation — and flags only what's sustained, which is what the user actually perceives.

The React DevTools Profiler is the tool that turns this entire module into a verifiable procedure. Its value is answering three questions with data: what rendered, how much it cost, and why. Without the third one, the other two only feed suspicions.

The complete method, exactly as you've applied it: measure in a production build (npm run build + npm run preview, with the alias to react-dom/profiling and keep_fnames so names stay readable), because development mode doubles renders with StrictMode, adds warnings, serves unbundled modules, and drags along source maps; locate in development, quantify in production. Record a single interaction per session, with "Record why each component rendered" always on. Read the commit timeline — each bar is one application of changes to the DOM, with a budget of 16 ms per frame — use the Ranked view to know what costs the most, and the Flamegraph view to know where it sits in the tree. And never confuse "render duration" (the component and its whole subtree) with "self time" (just itself): a parent at 214 ms with 0.8 ms of its own isn't the culprit, and that distinction decides whether the fix is memoizing, virtualizing, or changing an algorithm.

The "Why did this render?" section maps exactly onto 08-01's four causes, and each one has its answer: props changed, with the name of the culprit prop → stabilize it or pass primitives (08-03); state changed → correct, unless the state is in the wrong place (08-01); context changed → split the context and stabilize its value (07-02 + 08-03), where memo is useless; the parent component rendered → memo if the component is expensive or repeated (08-02), or isolate it with children. On top of that comes "Highlight updates", the five-second diagnostic that lights up in red whatever repaints too much.

CicloUrbano's case study has walked through the entire cycle with real numbers: six commits at ~220 ms with 2,014 components typing six letters; the exact diagnosis — Props changed: (onSelect, onBook); and the three fixes applied one at a time, measuring between each step. memo alone changed nothing, and that was a valuable result, not a failure: it confirmed that memoization without stable identities is pure cost. With useCallback commits dropped to 34 ms and cards started saying Did not render; with useDeferredValue, typing stopped competing with filtering. From 220 ms to 30 ms, from 2,014 components to 14, an INP of 240 ms down to 35 ms. And the final decision, as important as the previous ones: stopping, even though there was still technical headroom, because virtualizing would have added complexity and broken accessibility in exchange for an imperceptible improvement. You also know the <Profiler> API, with its onRender and the actualDuration/baseDuration pair, which directly measures what your memoization is saving, and you know the Profiler doesn't see everything: for layout, paint, network, and real users there's the Performance tab, Lighthouse, and web-vitals.

This closes Module 8. CicloUrbano no longer repaints 2,000 cards on every keystroke, doesn't recalculate what hasn't changed, doesn't create new functions where something compares identities, doesn't download the workshop panel to show the catalogue, and — worth the most — doesn't depend on anyone guessing anything: every decision in this module rests on a reproducible number, and the discipline of reverting what doesn't improve keeps the project from filling up with decorative optimization. But notice what it took to get here: BikeList's signature changed, state got relocated, two context providers' value got rewritten, the routes got split into nine chunks, and a lazy-loading layer with its own network failures got added. Nine refactors on code that already worked, with the only check being opening the browser and looking. That doesn't scale: next time someone stabilizes a dependency and a stale value slips through, or a memo stops updating a field, nobody will find out until a user reports it. Module 9: Testing in React takes on exactly that gap: why an application with no tests can't be refactored with confidence, what's worth testing and what isn't, and how to write checks that fail when behavior changes — not when the implementation changes. The next lesson is Introduction to Testing.