In the React DevTools Profiler, what do the Flamegraph and Ranked charts each show for a single recorded commit, and when would you switch from one to the other?
answer
- same commit, two projections
- one is the tree, one is a list
- width includes the subtree
- grey bars did not re-render
- ranked sorts by own render time
basics
~20 sFlamegraph draws a commit as the component tree, where a bar's width covers that component plus its subtree and components that did not re-render are greyed out. Ranked flattens the same commit into a list of components sorted by their own render time.
solid answer
~50 sBoth charts describe the **same selected commit**, projected differently. The Flamegraph keeps the tree shape: each bar is a component, its width is the time React spent rendering that component *and everything beneath it*, and components that bailed out in this commit are drawn greyed so you can see at a glance how much of the tree actually re-rendered. That makes it the view for the structural question — where did the update enter the tree, and how far did the cascade spread. The Ranked chart discards the hierarchy and lists only the components that did render, ordered by their **own** render time, largest first. That answers a different question — is any single component expensive by itself. I usually glance at Ranked first to see whether one component dominates; if the top entries are all small, I switch to Flamegraph, because that means the cost is breadth, not one hot component.
go deeper
Know that the Profiler records commits and that Flamegraph shows the tree while Ranked shows a sorted list, and be able to say you would click the tallest commit bar first.
Explain the mechanics: bar width in the Flamegraph is inclusive of the subtree, greyed bars did not re-render, and Ranked sorts only the rendered components by their own render time.
Show the diagnostic routine — worst commit, Ranked for a hot component, Flamegraph for a wide cascade — and say what each outcome implies about the fix you would pursue.
Frame the charts as two different questions about cost, depth versus breadth, and be ready to say when a profile is already good enough to stop reading and when the real bottleneck is not React render work at all.
## The unit both charts describe When you record with the React DevTools Profiler, the recording is not a continuous timeline — it is a sequence of **commits**. A commit is one batch of work React finished and applied to the DOM. The bar chart across the top of the Profiler tab has one bar per commit, sized and coloured by how long that commit took, and everything below it — Flamegraph or Ranked — describes **the single commit you have selected**, not the whole session. Selecting a different bar redraws both charts. Candidates who miss this read the charts as a timeline of the recording and draw wrong conclusions from them. ## The Flamegraph chart Flamegraph preserves the component hierarchy. Each row is a level of the tree, each bar is a component, and children sit under their parent. Two properties matter: - **Bar width is inclusive.** It is the time spent rendering that component *plus its entire subtree*, which is why the root is always the widest bar. A wide bar therefore does not mean "this component is slow"; it means "this branch was expensive in total". - **Components that did not render in this commit are still drawn, greyed out.** That is genuinely useful information: the coloured region shows exactly how much of the tree the update touched, so you can see whether an update to a filter input re-rendered a small subtree or repainted half the screen. Hovering a bar gives the component's own render time alongside the subtree total, and clicking one selects it so the right-hand panel can show its props, state and — if you enabled it before recording — the recorded reason it rendered. ## The Ranked chart Ranked answers the complementary question. It throws away the tree and lists **only the components that actually rendered in this commit**, one row each, sorted descending by **self time**: the time spent rendering that component's own function body, excluding its children. There is no nesting and no greyed entries, so the list is usually short and the top row is the honest answer to "is one component doing something expensive?" ## Self time versus subtree time This is the distinction the two charts are built on: - **Self time** — the cost of running one component's own render work. Expensive when the component does heavy computation, formats a large data structure, or builds a very large amount of JSX itself. - **Subtree time** — self time plus all descendants. Expensive either because one descendant is slow, or because there are simply a lot of descendants, each cheap. Flamegraph shows you subtree time by width and self time by tooltip; Ranked shows you self time only. A commit where the root's subtree time is large but every self time is tiny is a *breadth* problem — too many components rendered — and no amount of optimising a single component will fix it. ## Which chart to open first A practical order: 1. Pick the tallest commit bar — the worst commit is where the answer lives. 2. Open **Ranked**. If one component sits far above the rest, you have a self-time problem localised to that component and you can go read its code. 3. If the Ranked list is flat, switch to **Flamegraph** and look at how much of the tree is coloured. Walk up to the highest coloured component — the top of the re-rendering region is where the update entered — and ask why everything under it rendered. ## Reading traps - **Width is not badness.** The root bar is always full width; that is arithmetic, not a finding. - **The charts only contain what you did not filter out.** DevTools component filters (hiding host DOM elements, or components matching a name pattern) also remove rows from these charts, which makes them far more readable but means the chart is a filtered view, not the whole tree. - **Absolute milliseconds come from a development build on your machine**, so compare commits against each other and against a re-recording after your change rather than treating a number as a user-facing figure. - **A short Ranked list is a good sign.** The list length is itself a metric: it tells you how many components React ran for that one update.
- If the Flamegraph's root bar is always the widest, how do you find the component actually responsible for a slow commit?Walk *down* from the root through the coloured bars until the width stops being dominated by one child — that branch is where the time is. Then check the tooltip's own-render figure at each level: if no single component owns much of it, the cost is the number of components that rendered, and the useful target is the highest coloured component, which is where the update entered the tree.
- Why does the Flamegraph bother drawing greyed-out components at all?Because the ratio of coloured to grey is the finding. It shows how much of the tree the update actually touched, so you can tell a well-scoped update from a cascade that re-rendered an entire page. A Ranked chart cannot express that — it only lists what rendered, with no sense of what was skipped.
saying these in an interview costs you the question
- Says a Flamegraph bar's width is that component's own render time
- Thinks the Ranked chart lists every component in the application
- Reads either chart as a timeline of the whole recording
- Assumes a wide bar always means that component is slow
- Ignores the greyed bars and assumes the whole tree re-rendered