Typing into a filter input on a React screen feels sluggish. Walk through how you would use the React DevTools Profiler to locate the cause rather than guessing at it.

## Why a workflow question Interviewers ask this because performance work is where engineers most often optimise by folklore. The answer they want is a repeatable procedure with a measurement at the start and a measurement at the end. The tool detail matters less than the discipline. ## Step 1 — reproduce it under the recorder Open React DevTools, go to the **Profiler** tab. Before recording, enable the Profiler setting that records **why each component rendered** — it can only capture that data during the recording, so switching it on afterwards does nothing for a profile you already took. Start recording, then perform exactly the interaction that feels bad: type several characters into the filter at a natural speed. Stop. Keep it short — a few seconds of profile is easier to read than thirty, and the same commits repeat anyway. If the complaint were about the *initial* load of the screen rather than typing, the equivalent is the Profiler's **reload and start profiling** action, which restarts the page with recording already active so mount work is captured. Typing is an update, so plain record is right here. ## Step 2 — read the commit chart before anything else The bar chart across the top is one bar per commit. Two questions: - **How many commits per keystroke?** One is expected. Several per character means each keystroke is triggering multiple rounds of state updates, and the total the user feels is their sum — a finding in itself, independent of any single commit's duration. - **How tall are they?** A run of uniformly expensive commits during typing is the shape that produces "sluggish". ## Step 3 — dissect the worst commit Select the tallest bar and look at both projections of it: - **Ranked** lists only the components that rendered, sorted by their own render time. If one entry towers over the rest, you are done looking: the cost is inside that component and you go read its code. - **Flamegraph** keeps the tree, draws non-rendering components greyed, and sizes each bar by the component *plus its subtree*. If Ranked was flat, this is the view that matters: the ratio of coloured to grey tells you how much of the screen participated in a keystroke. ## Step 4 — find the entry point, not the symptom In the Flamegraph, walk **up** to the highest coloured component and select it. With the reasons recorded, its panel names why it rendered. That component is where the update entered the tree; the components beneath it will typically report that their parent rendered, which makes them consequences rather than causes. Optimising the bottom of a cascade is the most common wasted afternoon in React performance work. ## Step 5 — make the charts readable On a real application both charts are unusable at first because of sheer volume. DevTools component filters help: hiding host DOM elements collapses the tree to your own components, and filtering by name or location removes library wrappers you cannot change anyway. Filters apply to the Profiler charts as well as the Components tree, so the profile becomes a view of code you own. Just remember the chart is now a filtered view. ## Step 6 — change one thing, then re-record Make a single change, repeat the exact same interaction under the recorder, and compare: commits per keystroke, worst commit duration, and the number of rows in the Ranked chart. That last one is often the cleanest before/after number, because it counts components rendered rather than milliseconds measured on your machine. And treat the durations comparatively. They come from a development build on a developer machine, so the honest claim is "this interaction now commits four components instead of four hundred", not "this screen is now 40 ms faster for users". ## Step 7 — know when to stop Stop when the profile no longer shows React render work as the dominant cost of the interaction. At that point further render optimisation buys nothing, and if the screen still feels slow the cause is somewhere the React Profiler does not measure. Saying that out loud is a strong signal in an interview: the tool has a scope, and part of using it well is recognising when the answer is not inside it.