Reduce React Rendering Costs with Profiling

Create the fixture in a new local directory. The Product Explorer application itself uses no network data or external assets: it generates its deterministic 5,000-product dataset locally. The commands install the standard Vite React–TypeScript dependencies, then you will replace the generated source files with the complete sections in this step.

Keep StrictMode enabled. This baseline intentionally keeps query, selectedIds, and note in CatalogApp; do not optimize it yet.

Run these commands in a terminal from the parent directory where you want the project folder created.

Create src/data.ts and replace its contents with this complete deterministic data source.

Create src/catalog.ts and replace its contents. rankProducts does not mutate the source array and keeps the original product object references.

Replace src/App.tsx by pasting the following three sections consecutively, in order. Then replace src/main.tsx with the supplied file. No helpers are omitted: this is the unoptimized baseline used throughout the tutorial.

src/App.tsx — part 1 of 3

src/App.tsx — part 2 of 3

src/App.tsx — part 3 of 3

Replace src/main.tsx with this file. Keeping StrictMode is deliberate for this development baseline.

Start the local development server from the product-explorer directory, then open the Local address printed in your terminal.

Install the official React Developer Tools extension for your browser if it is not installed. With the local application open, open browser DevTools and locate the React DevTools Profiler panel. Its placement and control names can vary by browser and extension version.

A Profiler recording contains React commits during a bounded period. It is evidence about component render work; it is not a replacement for the browser Performance panel.

During the render phase, React calculates what component output should be. During the commit phase, React applies the necessary DOM changes. Therefore, a component function running does not automatically mean that the DOM changed. Neither event proves that pixels have painted on screen.

Keep this distinction when reading a recording: render duration is React component work, not a whole-interaction timing and not INP.

Use the same fixed scenario every time. Reset before each recording. Setup actions—including entering an initial query for Selection—stay outside the recorded interaction.

A Profiler recording is a sequence of commits, not one score for the entire trace. After recording one bounded scenario, locate the commits caused by the action itself. Ignore setup, initial mounting, and any warm-up work outside that action.

For example, a Note editing recording may contain several commits as the learner types. Inspect the commits associated with those keystrokes individually. A single unusually expensive commit can matter more than a low average that hides it.

A commit’s render duration describes component rendering associated with that commit. It is not a measurement of the whole interaction.

Use the flamegraph and ranked views together. The flamegraph shows where costly work sits in the component tree; the ranked view helps surface components contributing substantial render work. Exact controls and labels can vary by DevTools version.

Do not add a parent’s subtree duration to durations of descendants inside that subtree. Descendant work is already included. Compare either non-overlapping subtrees or a component’s own work at one chosen level of the tree.

Before a new recording, enable render-reason recording if your React DevTools version provides it. Then capture the same bounded scenario again. A reason such as state changed, props changed, context changed, or parent rendered is evidence about a trigger—not proof that the render was wasteful.

Do not infer a cause from flamegraph color alone. Combine the recorded reason, the component’s duration, and the source relationship you expect.

A state update starts at the component that owns that state. If CatalogApp owns the private note, every keystroke makes CatalogApp participate, bringing its sibling branches into the render scope.

note is consumed only by NoteEditor, so NoteEditor is its narrowest valid owner. In contrast, query coordinates the search control and product ranking, while selectedIds coordinates the visible list and the Selected products status. Keep those shared values in CatalogApp.

Do not push every value downward by default. Place state at the lowest boundary that must coordinate all of its consumers.

Make one ownership change in src/App.tsx: replace the old NoteEditorProps type and prop-based NoteEditor definition with this local-state component. The existing named useState import remains valid.

This keeps one authoritative note value. Do not create a second copy in CatalogApp and synchronize it with an Effect. Because NoteEditor stays mounted while searching or selecting, its note remains present during those interactions. If the application is unmounted and mounted again, the editor starts empty, as it did before.

Warm up without recording, then restore the fixed Note editing starting state: the note is empty. In React DevTools Profiler, start a fresh recording only after setup. Type review into Private note, then stop recording.

Inspect commits caused by those keystrokes. The prediction is that NoteEditor participates, while CatalogApp, ProductSummary, ProductList, and ProductRow do not participate because of this note update. Record Filtering and Selection separately when needed; moving note state does not itself predict a reduction for those scenarios.

React.memo is a component-boundary optimization. When a parent updates, React can skip rendering a memoized child when every received prop compares equal to its previous value.

This is an opportunity to skip parent-driven work, not a promise that a component will never render. In Product Explorer, Filtering changes query in CatalogApp, while ProductSummary continues to receive the same immutable module-level PRODUCTS reference. Earlier profiling made this summary a candidate worth testing.

State locality remains the better first response when a frequently updated value is private to one component. Memoization is justified only when the measured boundary has meaningful work to avoid.

By default, memo compares every prop with Object.is. It does not inspect the contents of an array, object, or function. Equal-looking values are not enough: their identities must compare equal.

A memoized component can still render when its own state changes or when a context value it consumes changes, even if its parent passes equal props. Use relevant Profiler commits and render reasons to check whether the boundary actually avoided useful work.

Make only the following incremental edits in src/App.tsx. Preserve the existing ProductSummary markup, the local NoteEditor state from the previous step, and all of CatalogApp except its one summary element. Do not change the ranking call, list, search, note, or selection behavior.

The wrapper creates a memoized version of the existing component. Its products prop remains the same stable PRODUCTS reference.

src/App.tsx — make these three targeted edits to the existing file

Start with evidence, not the presence of a large list. In the Selection scenario, reset Search products to tools, warm up outside the recording, reset again, then record the two checkbox toggles in React DevTools Profiler.

Inspect the relevant commits and the source. rankProducts(PRODUCTS, query) reads the product collection and query; it does not read selectedIds. Before caching, a CatalogApp render caused by selection can repeat filtering and sorting 5,000 products although the ranking inputs are unchanged.

That makes a narrow hypothesis: reuse the pure, already-limited visible-product calculation during Selection without preventing selection state from updating the list.

Cache the complete visible-result calculation inside CatalogApp. Add useMemo to the existing named React import, replace the direct ranking expression, and pass visibleProducts to ProductList.

The calculation still ranks all matching products, then non-mutatingly keeps only the first 50. It preserves the existing interface behavior and product object references. Its dependencies are every reactive value read by the calculation: PRODUCTS and query. React compares dependencies with Object.is.

During Selection, CatalogApp can render because selectedIds changed, but unchanged PRODUCTS and query allow React to reuse visibleProducts. During Filtering, query changes, so the cache invalidates and the correct first 50 ranked matches are calculated again.

In src/App.tsx, replace the current React import and the direct rankedProducts calculation. Then replace the existing ProductList prop value with visibleProducts.

Complete the cache that calculates the same first 50 visible matches as the original expression.

memo(ProductRow) can skip parent-driven rendering only when its relevant props compare equal. A callback declared again during every CatalogApp render is a new function reference, even if it would perform the same selection update.

In the Selection scenario, immutable product objects and an unchanged row’s selected value can remain stable. If onToggle also remains stable, unchanged memoized rows become eligible to skip parent-driven work. The toggled row receives a different selected value and must render so its checkbox stays correct.

This is a measured optimization: use it only if your Selection profile identifies meaningful row work to avoid.

useCallback reuses a function reference while its dependencies compare equal. It does not cache execution: when a checkbox change calls onToggle, the callback body still runs and updates selection.

Use a functional setSelectedIds update so handleToggle receives the current selection as current; it does not need to capture selectedIds. Therefore this callback can use []. If the callback reads any other reactive value, include that value in its dependency list.

Keep the stable function at the memoized row boundary. Each row may still create its small event handler to supply its own product ID.

In src/App.tsx, make these replacements in the existing file. handleToggle is inside CatalogApp, where its Hook and setSelectedIds are valid. This assumes the visibleProducts calculation from the previous step remains in CatalogApp.

Treat an optimization as a controlled experiment, not a one-off fast recording. Change one hypothesis at a time. For every relevant scenario, record at least three runs before and three runs after the change.

Keep the data, scenario starting state, browser and extension versions, build mode, React DevTools settings, viewport, CPU throttling, and Strict Mode status identical. Reset before every recording; setup and warm-up actions remain outside the recording.

In React DevTools Profiler, compare the commits caused by the interaction, the participating components, and one consistently defined render-duration summary. For example, calculate the median relevant-commit render duration for each run, then report the range across the three run medians.

A render duration measures React render work in a commit. It is not whole-interaction latency, browser paint time, or INP.

Development profiling and an optimized-build interaction check answer different questions. Keep React DevTools Profiler comparisons development-to-development, with the same Strict Mode setting and profiling overhead. Strict Mode can repeat development checks, and profiling itself adds overhead.

After the comparable profile runs, build locally and inspect the same fixed scenario separately with the browser Performance panel. Record the user action, then inspect its event work, main-thread activity, and presentation-related activity. This can support a local interaction observation, but it does not establish an INP claim.

Use the same data, starting state, viewport, and throttling. A normal optimized build does not provide the same Profiler instrumentation by default, so never compare a development Profiler render duration directly with a browser timing from preview.

Build the local optimized bundle, then serve it locally. Open the Local address printed by preview and record the same fixed scenario in the browser Performance panel.

Behavior checks protect the user task while you evaluate cost. The supplied tests verify query-dependent catalog results, selection and deselection, note independence, keyboard checkbox operation, the required accessible checkbox names, focus continuity, and visible selection state.

They deliberately do not assert render counts or timing thresholds. Those are implementation details that vary by machine and mode. The files below run against the cumulative Product Explorer fixture after the state-locality and memoization changes from the preceding steps.

Create these two files. They configure Vitest with jsdom and load the Testing Library matchers used by the focused suite.

Create src/App.test.tsx. The deterministic ranking places Product 1027 — Books — score 999 among the first 50 Books results, while Product 0027 — Tools — score 999 is excluded by that query.

Install the local test dependencies if they are not already present, then run the focused suite once. Investigate a failing behavior check before keeping an optimization.

A profiling decision is defensible when every link is explicit:

1. Locate significant work in relevant Profiler commits.
2. Explain the trigger with render reasons and component relationships.
3. Choose the smallest change that addresses that trigger—or choose no change.
4. Predict and verify the affected scenario with comparable recordings and behavior checks.

Do not optimize because a component rendered. Optimize when the measured work, its cause, and a safe intervention form one testable claim.

Consider this compact Product Explorer case. In the Note editing scenario, the learner resets the note to empty, warms up the app, then records typing review. The Profiler shows a state update in CatalogApp; NoteEditor, ProductSummary, ProductList, and 50 visible ProductRow components participate because their parent rendered.

The note is private: no sibling reads it. The products reference, query, selection, and summary inputs are unchanged. Render reasons support the update path; color alone would not be enough evidence.

A concise evidence report contains six parts:

• Scenario and starting state
• Observed render evidence and trigger
• Hypothesis
• Smallest intervention
• Comparable before/after result or missing evidence
• Behavior checks and decision: keep, revert, or investigate

Name what was measured. If an optimized-build interaction check or an after recording is missing, say so; do not fill the gap with an invented number.