Module 7 ended with an uncomfortable diagnosis: CicloUrbano knows where every piece of data lives and why, but it doesn't go fast. There are components repainting for no reason, calculations redone on every render, and a bundle the browser downloads in full before it shows the first bike. The natural temptation at this point is to open the editor and start sprinkling memo and useMemo across the project until "it feels better." That temptation is exactly what this lesson is here to defuse. Optimizing without measuring isn't optimizing: it's adding complexity blindly and hoping it pays off. Before touching a single line you need to know what "slow" means to the user, why a component re-runs, what's genuinely expensive and what isn't, and — most important of all — that most performance problems in a React app are best solved without memoizing anything. This lesson is the big picture and the method: the techniques that almost always pay off more than memoization, the role of React 19's React Compiler, and the workflow that structures the whole module. The memoization tools arrive in the lessons that follow, and they arrive better prepared thanks to this one.

1. The rule that governs the module: measure first
2. The real cost of premature optimization
3. What "slow" means in an interface: the metrics that matter to the user
4. Why a component re-runs
5. The ecosystem's most expensive misunderstanding
6. Technique 1: lower state to the component that uses it
7. Technique 2: pass children to isolate a subtree
8. Technique 3: derive during render instead of storing and syncing
9. Technique 4: stable keys in lists
10. Technique 5: delay and throttle text input
11. Technique 6: paginate and virtualize long lists
12. Technique 7: take work off the main thread
13. React 19's React Compiler: what it automates and what it doesn't
14. Performance budget and workflow
15. Map of the rest of the module

Don't optimize what you haven't measured. If you can't point to a number that's getting worse, you don't have a performance problem — you have a suspicion.

This rule sounds like a manual platitude and is an engineering decision with very concrete consequences. The reasons intuition fails at web performance are systematic:

• Your machine isn't the user's. You develop on a powerful laptop, the app on localhost, with no network latency. CicloUrbano's user opens the catalogue on a mid-range phone, on patchy 4G, while walking to the station.
• Development mode lies. Vite's dev server serves unbundled modules, React logs warnings and debug information, and StrictMode runs every component twice. A render that takes 18 ms in development can take 4 ms in production.
• What feels slow and what is slow rarely match. A 300 ms render on a button click is a perceived disaster; the same amount of work spread across a background setTimeout goes unnoticed by anyone.
• Bottlenecks hide. The component you suspect is almost never the culprit. In CicloUrbano, the reason typing in the search box feels sluggish isn't the <input> — it's the cards repainting behind it.

The practical consequence is that the correct order of work always starts with lesson 08-05 (the Profiler), even though it's the last one in the module. This module is studied in order because you need the tools to understand what the Profiler shows, but it's applied in reverse order: measure, locate, fix, measure again.

When someone says premature optimization is expensive, they usually stay abstract. Here are the real costs, one by one.

By far the most serious is the fourth one. An unnecessary memo slows things down a little; a useMemo with the wrong dependencies produces incorrect data on screen, and that failure is intermittent, hard to reproduce, and usually gets discovered by a user.

A performance bug makes the app slow. A memoization bug makes the app lie.

"Slow" isn't a feeling: it's a set of measurable quantities. These are the ones the industry has settled on (the so-called Web Vitals), what they mean, and — the key fact for this module — how much React can do about each one.

Two conclusions from this table structure the whole module:

1. INP and TBT are React's territory. When typing in BikeSearch takes 400 ms to show up, that's INP, and it gets fixed with memoization, useDeferredValue, or virtualization (08-02, 08-03).
2. FCP and LCP are mostly the bundler's territory. No memo fixes the browser having to download 1.2 MB of JavaScript before painting the catalogue: code splitting does (08-04).

And a third, uncomfortable one: there are causes of slowness that aren't React's at all and no technique in this module will touch — station photos that aren't compressed or sized, a json-server query that returns all 2,000 bikes unpaginated, fonts that block painting, or a cascading request that waits on another one. Before memoizing anything, make sure the problem is where you think it is.

01-05 established React's cycle: render → diff → commit. Now comes the part that model left implicit: what makes React call a component's function again. There are only four causes, and there's no fifth.

Notice what's not on the list: "its props changed." Props don't trigger anything on their own. A component receives new props because its parent re-ran (cause 2), and that's the correct causal order.

Here's the sentence you need to internalize before writing a single memo:

A component re-rendering doesn't mean the browser repaints anything. It means React calls a JavaScript function again and compares the result.

A render is: run the component's function, get a tree of lightweight objects (React elements), compare it with the previous one, and apply to the DOM only what changed. If BikeCard returns exactly the same JSX as before, the DOM isn't touched. This completely changes the scale of the problem:

The correct reading: an extra render isn't a bug, it's a data point. A hundred renders of trivial components can be irrelevant; a single render that sorts a 2,000-item array and formats 2,000 dates can wreck the interaction. That's why the goal is never "reduce the number of renders," but reduce the work done per interaction. With that distinction clear, the seven techniques that follow explain themselves: all of them eliminate work, they don't speed it up.

It's the most cost-effective technique of all, and it needs no new API. If a piece of state sits higher than where it's needed, every change re-runs a much larger subtree than necessary. The fix is to move it down: it's the inverse operation of "lifting state up" from 04-01, and it answers the same question — who needs this data? — with the opposite answer.

Every keystroke in the hours field re-runs NewBookingPage, and with it FleetSummary — which aggregates all 2,000 bikes by status — and Breadcrumbs. The field types a number and the cost is a full recount of the fleet.

Now typing in the field re-runs a single component. No memo, no useCallback, no dependencies to maintain. And the code is shorter than before, not longer: that's the sign that the optimization is structural, not a patch.

The operating rule, which you already saw in 07-01 when classifying state: place each piece of state at the lowest common ancestor of whoever reads it, not higher.

When state can't be lowered because the very component wrapping the rest is the one consuming it, there's a second structural technique, which already showed up in 04-02 and here reveals its real usefulness. The trick is in how children works: the JSX passed as children is created in the parent component, not in the one that receives it. If the parent doesn't re-run, those elements are literally the same objects as before, and React skips rendering them.

Opening the sidebar re-runs Layout, and with it <Outlet /> and the entire page underneath: the catalogue with its 2,000 cards. A purely decorative change to the frame costs a render of the whole application.

Now setSidebarOpen re-runs only FrameWithSidebar. The children prop it receives is the same object as in the previous render, React detects that by identity, and doesn't descend down that branch. The catalogue never finds out.

This technique is sometimes called "structural memoization": it gets memo's effect without memo, without comparison, and without extra memory — just by putting the state in the right spot in the tree.

The third technique doesn't reduce renders: it reduces work and eliminates an entire class of bugs. It's the same lesson from 05-02 about unnecessary effects, read now through the lens of performance.

This component does two renders per change: one with the old value and another after the effect. On top of that, it shows incorrect data for an instant, and if bikes changes identity without changing content, the effect fires anyway.

A single render, impossible to desync, and less code. The question that immediately comes up — "what if the calculation is expensive?" — is answered in 08-03 with useMemo, but the order matters: derive first, and only memoize if measuring shows the calculation is heavy. Storing in state what can be computed is a correctness problem before it's a speed one.

03-03 established why key isn't decoration. From a performance angle, the effect of a badly chosen key is brutal and silent.

With 2,000 cards and catalogueSlice's sort switching from precio to modelo, the difference between the first and the third option is the difference between a smooth animation and a half-second freeze. And it costs nothing: it's just writing the right key.

useDebounce has been in the project since 05-06, and BikeSearch uses it. It's worth revisiting now for what it actually is: a performance technique that reduces how often work happens rather than reducing its cost.

The key to the pattern: the <input> keeps updating on every keystroke (it's a cheap component and its response needs to be instant), but filtering the 2,000 bikes happens exactly once, 300 ms after the last keystroke. Typing "electrica" goes from 12 filter passes down to 1.

Its close relative is throttling, which instead of waiting for silence guarantees at most one execution every X milliseconds. It's the right choice for continuous events that have no "end": scrolling, resizing, mouse movement.

How to choose between the two:

Suppose CicloUrbano grows and db.json ends up with 2,000 bikes spread across the city — this is the scenario the module will use from here on. Painting 2,000 BikeCards means creating on the order of 20,000 DOM nodes. No amount of memoization fixes that, because the work is real: the browser has to lay out and paint everything that exists.

There are two answers, and the first is almost always the better one:

Paginate. json-server already supports _page and _limit, and 07-06 set up the paginated query with placeholderData so the list doesn't flicker. If the user sees 24 bikes per page, the problem disappears at the root: there are never more than 24 cards in the DOM, and less data gets downloaded too.

Virtualize (or "sliding window"). When the design calls for a continuous, infinitely scrolling list, the technique is to mount only the visible elements plus a small margin, and simulate the total height with an empty container so the scrollbar stays believable.

Today's standard library is @tanstack/react-virtual, from the same authors as TanStack Query, with no dependencies and framework-agnostic.

Point by point:

1. count is the logical number of elements; the virtualizer never iterates over all of them.
2. getScrollElement returns the element with overflow: auto that produces the scroll.
3. estimateSize can be approximate: if heights vary, it's corrected by measuring with measureElement.
4. overscan mounts a few elements outside the view so a fast scroll doesn't show gaps.
5. The inner container has the real total height (2,000 × 120 px = 240,000 px) even though it's nearly empty.
6. transform: translateY(...) is preferable to top because it doesn't trigger a layout recalculation.

The result in numbers: from ~20,000 DOM nodes to ~140. No other technique in this module comes close to that improvement. Before memoizing a long list, ask yourself whether it should be short.

Honest warnings about virtualization, because it isn't free: it breaks the browser's find function (Ctrl+F can't find what isn't mounted), it complicates accessibility and keyboard focus, it demands care with variable heights, and it interferes with printing. That's why pagination is usually the better product decision.

The browser has a single thread to run JavaScript, respond to events, and paint. Anything that occupies that thread for more than ~50 ms turns into an unresponsive interface. The levers, from simplest to most complex:

An example of the last case, often overlooked because it isn't "React code":

Two lines of CSS that stop the browser from laying out cards that are off-screen. It isn't virtualization — the nodes still exist in the DOM — but the layout and paint cost drops a lot, and it needs no library at all.

React 19 stabilized the React Compiler, and it's worth explaining precisely because it produces two opposite misunderstandings: the person who thinks memoization no longer needs learning, and the person who ignores it entirely.

What it is. A compiler that runs at build time (like a Babel plugin inside Vite), analyzes your components and hooks, and automatically inserts the memoization you would have hand-written with memo, useMemo, and useCallback. It turns your code into an equivalent version that reuses values, functions, and JSX elements when their inputs haven't changed.

How to enable it in Vite:

And the golden rule for adopting it sensibly: before turning it on, run the React rules linter (eslint-plugin-react-hooks includes the compiler's rules). The compiler is conservative: if it detects a component breaking React's rules — mutating props, writing to a module-level variable during render, reading ref.current while rendering — it skips that component and leaves it unoptimized, silently. A project with lots of violations gets far fewer improvements than it expects.

What it automates and what it doesn't:

Why this module is still essential, even if you turn the compiler on tomorrow:

• To read existing code. The vast majority of React projects in production are full of hand-written memo, useMemo, and useCallback. You can't maintain what you don't understand.
• To debug. When something goes wrong with the compiler enabled, diagnosing it requires knowing exactly what memoization was expected and which one didn't show up.
• Because many projects won't adopt it. Large codebases, older React versions, build chains that don't use Babel.
• Because it doesn't remove judgment. The compiler memoizes; it doesn't decide what's worth calculating, what should be paginated, or where state should live. That's still the hard work.
• Because memoizing isn't optimizing. If the problem is that you're downloading 1.2 MB of JavaScript or requesting 2,000 records, the compiler doesn't help at all.

The React Compiler removes the mechanical work of memoizing. It doesn't remove the need to understand what gets memoized, why, and when that isn't the solution.

A performance budget turns "this feels slow" into a checkable condition. Without one, there's no way to know when to optimize or, above all, when to stop. This is a reasonable budget for CicloUrbano:

And this is the workflow that structures the whole module. Read it as a loop, not a list:

Two details in the diagram that aren't decorative:

• "Apply a single technique at a time." If you apply memo, useCallback, and virtualization all at once and things improve, you don't know which one did it; you're probably carrying two useless optimizations forever.
• "Revert the change." An optimization that doesn't measurably improve anything must be undone. Its cost in readability and memory is still there even when the benefit isn't.

Optimizing in development mode. Vite's dev server, React's warnings, and StrictMode's double render distort any measurement. Anything measured for real gets measured with npm run build and npm run preview (08-05).

Chasing the render count as a goal. "I went from 340 renders to 12" isn't an achievement if the interaction took 30 ms and still takes 28. The metric is time, not the count.

Starting with memoization. It's the order reversed. By the time you reach memo having already ruled out lowering state, children, deriving, paginating, and virtualizing, the memo is usually unnecessary. When you start with memo, you almost always end up with a project full of memoization and the real problem untouched.

Tip: measure on a slow device. Browser devtools let you throttle the CPU 4× or 6×. A problem that's invisible on your laptop becomes obvious at 4×, which is roughly a mid-range phone.

Tip: put the problem in its layer. Before touching React, check image sizes, the number of requests, whether the server paginates, and whether fonts block painting. Many "slow React apps" are apps with 3 MB of images.

Tip: write the budget into the repo. A PERFORMANCE.md file with the five figures from section 14 turns a discussion of opinions into an objective check, and it survives team changes.

Tip: turn on the linter's rules before the compiler. eslint-plugin-react-hooks with the React Compiler's rules tells you which components break React's rules. Fixing them improves the code even if you never turn on the compiler, and it's a prerequisite for the compiler to be worth anything.

Exercise 1. The following CicloUrbano component causes typing in the notes field to repaint the whole bookings panel, including BookingsPanel, which aggregates the user's full history. Identify the problem, say which technique from this lesson fixes it, and rewrite the component.

Exercise 2. For each CicloUrbano symptom, say which metric from section 3 gets worse and which technique from this lesson (or which lesson in the module) is the right one. Don't use memo, useMemo, or useCallback in any answer.

Exercise 3. A coworker proposes turning on the React Compiler and deleting every memo, useMemo, and useCallback in the project "because now they're automatic." List at least four concrete technical objections and describe what check you'd run before accepting or rejecting the proposal.

Solution 1. The problem is misplaced state: note is only used by the <input> and the button, but it lives in BookingsPage, so every keystroke re-runs BookingsPanel and FleetSummary. The technique is technique 1, lowering state (section 6), by extracting the field and its button into their own component.

Now typing re-runs only InternalNoteField. There's no need for memo on BookingsPanel or on FleetSummary: React doesn't even descend down that branch. It's the module's structural lesson: the best optimization is the one that makes optimization unnecessary.

Solution 2.

None of the five gets solved by memoizing. That's exactly the point of the exercise.

Solution 3. Objections:

1. The compiler doesn't memoize what it can't analyze. If a component breaks React's rules, it skips it silently; deleting the manual memoization leaves those components worse off than before, with no warning at all.
2. It doesn't cover external dependencies. A function imported from a utility, or an options object created outside the component, still need human judgment; the compiler reasons inside the component only.
3. It doesn't make expensive calculations cheap. Sorting and filtering 2,000 bikes costs the same the first time; the compiler avoids repeating it, not doing it.
4. It breaks the code for whoever hasn't turned it on. If part of the project gets extracted into a shared library, or another team builds without the plugin, the memoization disappears.
5. It removes implicit documentation. A useMemo with explicit dependencies communicates a design intent that the code without it no longer expresses.
6. It's effectively an irreversible change. Reintroducing manual memoization across hundreds of components costs far more than leaving it be.

Check to run first: measure before and after with the Profiler (08-05) on the critical interactions — typing in the search box, changing the sort, opening the BookingDialog — on a production build, with and without the compiler, and with the React rules linter green. If the numbers come out equivalent, the compiler is doing its job and removing the manual memoization can be considered gradually, component by component, not in one single operation.

This module starts with method because without method, optimization is superstition. The rule governing everything is measure first: if you can't point to a number breaking a budget, you don't have a problem, you have a suspicion, and acting on suspicions costs readability, memory, and — worst of all — dependency bugs that make the app show incorrect data.

"Slow" has been turned into concrete quantities: FCP and LCP depend mostly on bundle size and the server; INP and TBT are React's own territory and this module's; CLS gets wrecked by badly designed loading indicators. And the causal model has been fixed in place: a component re-runs for four reasons — its state, an ancestor, a context it consumes, a subscribed external store — and "its props changed" isn't among them. Hence the ecosystem's most expensive misunderstanding, now defused: re-rendering isn't repainting. A render is running a function and comparing the result; the DOM only gets touched where something changed. What's expensive isn't the renders, it's the work per interaction.

With that settled, the seven techniques that almost always pay off more than memoization: lowering state to the component that uses it (the most cost-effective of all, and it shortens the code too), passing children so a subtree keeps its identity and React doesn't descend down that branch, deriving during render instead of storing and syncing with an effect, stable keys in lists — where a key={index} turns a re-sort into a full DOM rewrite —, useDebounce and useThrottle to reduce how often work happens, paginating or virtualizing with @tanstack/react-virtual once the catalogue grows to 2,000 bikes, and taking work off the main thread with precomputation, CSS, and content-visibility. None of them needs memo.

React 19's React Compiler has been presented without exaggeration: it automates the mechanical memoization you would have hand-written, it doesn't shrink the bundle, it doesn't make an expensive calculation cheaper, it doesn't reason about external dependencies, it silently skips code that breaks React's rules, and it makes no structural decisions. You still need to understand manual memoization to read existing code, to debug, and for the projects that won't adopt it. And the workflow that structures the module: measure → locate → apply the simplest technique, one at a time → measure again → revert if it doesn't improve.

Now it's finally the tools' turn. The first one answers cause 2 from the list — "an ancestor has re-rendered" — for when there's no structural room left to avoid it: wrapping a component so React compares its props and skips running it if they're the same. The next lesson is Memoization with React.memo.