React DevTools has a General setting called "Highlight updates when components render". What does it do on the page, and what would you use it for?
answer
- a live overlay, not a recording
- outlines the regions that re-rendered
- colour tracks update frequency
- triage before you profile
- shows renders, never durations
basics
~20 sIt flashes a coloured outline around each region of the page whose component just re-rendered, with the colour shifting as a region updates more often. It is a zero-setup way to see which parts of the screen react to an interaction, but it gives no timings.
solid answer
~50 sTurning it on makes DevTools draw a brief outline around the DOM area of every component that re-renders, right on the page, and the outline colour shifts as a region updates more and more frequently. You use it as a **first pass**, before opening the Profiler: type one character into a form field, or hover one row of a table, and watch what lights up. If only the input outlines, the update is well scoped; if headers, sidebars and unrelated lists flash too, you have found where to point a real recording. What it does *not* give you is numbers — no commit durations, no per-component render time, no reason a component rendered. So it answers "is anything obviously re-rendering that shouldn't?" in about ten seconds, and then you switch to the Profiler tab for the measurement that supports an actual decision.
go deeper
Know where the setting lives in DevTools and be able to say plainly that it outlines the screen regions that just re-rendered, so you can see whether an interaction updates more of the page than it should.
Explain its limits: it reports that a render happened, not its cost, its cause, or which component in a nested stack it was, so it is triage that has to be followed by a Profiler recording.
Show the judgment to stop at the overlay when nothing unexpected lights up, and to use the idle case — regions flashing with no user input — as a signal about timers and subscriptions.
Be ready to argue where a cheap always-on signal like this belongs in a team's workflow, and why encouraging engineers to chase every highlight produces optimization work with no measured payoff.
## What the setting is In React DevTools' settings there is a General option, **"Highlight updates when components render"**. It is off by default. With it on, whenever React re-renders a component, DevTools briefly paints an outline around the screen area that component occupies. Nothing is recorded and nothing is stored — it is a live overlay you watch while you use the app. ## What you actually see Interact with the page and outlines blink around the affected regions. The colour of the outline reflects how frequently that region is updating: an area that updates once looks different from one that is updating continuously, with the colour moving from cool to warm as update frequency climbs. Practically, a region that is constantly warm is one that is re-rendering far more often than the user is doing anything, which is worth understanding even before you measure it. ## Why it is useful Profiling has a cost in attention: you record, you pick a commit, you read two charts. The highlight overlay costs nothing and answers a coarser question instantly — **is the update scoped to where I made the change?** Typical uses: - **Typing in a form field.** Ideally the field and any live-validation message outline. If the page header, the navigation and a data table also flash on every keystroke, that is your lead. - **Hovering or selecting a row in a list.** A hover state that outlines the entire list rather than one row tells you where the state lives. - **Idle observation.** Leave the app alone and watch. Anything that keeps flashing with no user input is being driven by a timer, a subscription or a polling call, and that is worth knowing. ## What it deliberately does not tell you This is the half candidates skip, and it is the half interviewers care about: - **No durations.** An outline means "this rendered", not "this was slow". A component can re-render every keystroke and cost nothing at all, and chasing every flash is a good way to waste a day. - **No reason.** The overlay never says whether a prop changed, context changed, or the parent simply rendered. - **No structure.** You see screen regions, not the component tree, so you cannot tell which component in a nested stack actually re-rendered — several nested components occupy roughly the same rectangle. - **Renders with no visible box are invisible.** A component that renders nothing to the screen, or occupies zero area, has nothing to outline. ## How it fits the workflow The honest framing is triage. Highlight updates is the smoke detector; the Profiler is the investigation. Turn the overlay on, reproduce the interaction that feels slow, and note which regions light up unexpectedly. Then turn it off and record a real profile of the same interaction, so you have commit durations and — if you enabled the corresponding Profiler setting — a recorded reason for each render. Deciding to change code on the strength of the overlay alone is the mistake: it shows re-rendering, and re-rendering is only a problem when it is expensive. ## One caution The overlay itself is drawing on the page while you watch, so it is an observation tool, not a measurement tool. If you want numbers, take them from the Profiler with the overlay off.
- A component outlines on every keystroke. Is that automatically something to fix?No. The overlay only proves the component re-rendered, and re-rendering is React's normal way of responding to state changes. It becomes a problem when the render is expensive or the region is large — and the overlay cannot tell you either of those. You confirm it in the Profiler: if the commit is a couple of milliseconds, leave it alone.
- You leave the app idle and a region keeps flashing. What does that suggest?Something is driving state changes without user input — an interval, a subscription pushing values, a polling request, or an animation writing to state. It is worth chasing because that work continues for as long as the tab is open. The next step is a Profiler recording of the idle period to see how expensive each of those commits actually is.
saying these in an interview costs you the question
- Thinks the outline colour indicates how slow a render was
- Treats every highlighted region as a performance bug to fix
- Confuses the overlay with the Profiler's recorded commits
- Expects it to show which component rendered in a nested stack
- Assumes it works without React DevTools installed