React DevTools has a Profiler setting labelled "Record why each component rendered while profiling". What does enabling it give you, and what does it cost?
answer
- quantitative profile becomes qualitative
- answers why, not just how long
- it names the changed props
- must be enabled before recording
- bookkeeping inflates the durations
basics
~20 sWith that setting on, selecting a component inside a profiled commit shows why it rendered: it was mounting for the first time, specific props changed, its state or hooks changed, context changed, or its parent rendered. The extra bookkeeping makes the profiling session slower.
solid answer
~50 sWithout it, the Profiler tells you *what* rendered and how long it took; with it, DevTools also records *why* each component rendered, and shows that reason in the right-hand panel when you select the component in a commit. The reasons are the ones that actually cause a render: this was the first render, one or more named props changed, state or a hook changed, a context it consumes changed, or simply that its parent rendered. The named-props detail is the valuable part — it points straight at the prop to investigate instead of leaving you to diff by hand. The costs are that it must be enabled **before** you record, since the data is captured during profiling and cannot be added to an existing profile afterwards, and that the bookkeeping adds overhead to the session, so I trust the reasons more than the absolute milliseconds when it is on.
go deeper
Know that this option exists in the Profiler settings, that it must be switched on before you record, and that it makes DevTools tell you why a component rendered rather than only how long it took.
Be able to list the reasons it reports — first render, named props, state or hooks, context, parent rendered — and explain that the named props are the actionable part.
Demonstrate the workflow: read the reason on the highest rendering component to find where the update entered, treat the cascade beneath it as a consequence, and re-record without the setting when you need trustworthy timings.
Own the judgment that a reason is evidence, not a verdict, and be ready to say how you would keep a team from optimising every "parent rendered" line it sees instead of the few commits that actually cost users anything.
## What the setting is The React DevTools Profiler has its own settings section, and one of the options there is **"Record why each component rendered while profiling"**. It is off by default. It changes what DevTools stores during a recording, not how React behaves. ## What you get with it off A profile without it is purely quantitative. You get the commit bar chart, and for any selected commit, the Flamegraph and Ranked views telling you which components rendered and how long each took. That is enough to answer "where did the time go", but not "why did this component run at all" — and in React the second question is usually the one that leads to a fix, because most slow screens are not one slow component but too many components rendering. ## What you get with it on Select a rendered component inside a commit and the right-hand panel adds a **"Why did this render?"** section. The reasons correspond to the ways a render is triggered: - **First render** — the component was mounting, so there is nothing to compare against. - **Props changed** — and DevTools names the props, which is the single most actionable line in the whole tool. A prop listed as changed on every keystroke is a lead you can follow directly to the code that produces it. - **State changed / hooks changed** — the component updated itself. - **Context changed** — a context it consumes published a new value. - **The parent rendered** — nothing about this component's own inputs changed in a way React could bail out on; it ran because its parent ran. That last reason is the one people misread. It is not an error message and it is not always a problem: re-rendering a cheap component because its parent rendered is React's normal, correct behaviour. It becomes a finding only when a large subtree carries that reason and the commits are expensive. ## The costs Three, and an interviewer will expect at least two: 1. **It must be on before you record.** The reasons are captured while profiling. Enabling the setting after a recording does not retroactively annotate that profile — you re-record. 2. **It adds overhead.** DevTools does extra bookkeeping per component per commit, and that work happens inside the measured session. Treat the absolute durations from such a profile as inflated, and if you specifically want timing numbers, record a second pass with the setting off. 3. **It needs a build React can be profiled in.** The Profiler works against a development build or a build with profiling enabled; against a plain production build the Profiler cannot record at all, with or without this option. ## How it changes the workflow The practical loop becomes: record the interaction with the setting on, select the worst commit, find the *highest* component in the Flamegraph that rendered, and read its reason. That component is the entry point of the update. Everything under it will typically say "the parent rendered", which tells you the cascade is a consequence, not the cause — so you fix the top, not the bottom. Then, if you need honest timings for a before/after comparison, re-record with the setting off so the measurement is not carrying the instrument's own cost. ## Reading the reasons honestly A reason is a fact about this commit, not a verdict. "Props changed: items" tells you React saw a different value for `items`; it does not tell you whether the underlying data actually differed or whether a new value was produced with the same content. Distinguishing those two cases is the work you do after the Profiler hands you the prop name — the tool's job ends at naming it.
- You recorded a profile and only then realised the setting was off. Can you recover the reasons from that recording?No. The reasons are captured while profiling, so a recording made with the option off simply does not contain them, and toggling it afterwards annotates nothing. You enable it and record the interaction again. That is worth knowing before you spend effort reproducing a hard-to-trigger interaction — turn the setting on first.
- Most components in a slow commit report "the parent rendered". Is that a defect?Not by itself — a component re-rendering because its parent did is React's default behaviour, and for cheap components it is fine. It becomes a finding when the commit is expensive and that reason covers a large subtree, because then the cost is breadth. The actionable component is the highest one in the tree whose reason is something other than the parent.
saying these in an interview costs you the question
- Thinks the setting can be applied to an already-recorded profile
- Believes it changes how React itself renders, not just what DevTools stores
- Treats "the parent rendered" as automatically a bug
- Ignores that the extra bookkeeping inflates recorded durations
- Assumes a changed prop means the underlying data actually differed