How would you use React Profiler to find unnecessary re-renders?

WHAT THIS TESTS: The interviewer wants to know if you can move beyond console logging and use React's built-in instrumentation to diagnose render performance. Specifically they are checking whether you understand the programmatic Profiler API, how to interpret its onRender callback arguments, and how to distinguish between optimized and unoptimized component subtrees using quantitative timing data rather than guesswork.

A GOOD ANSWER COVERS: First, you would wrap the suspected component subtree in a Profiler component and provide an onRender callback. Second, inside onRender you would inspect the phase parameter to filter for update renders rather than initial mounts, since unnecessary re-renders are a concern during updates. Third, you would compare actualDuration against baseDuration; actualDuration measures the milliseconds spent rendering the profiled tree in the current commit, while baseDuration estimates the worst-case time to render the entire subtree without optimizations. When actualDuration is significantly lower than baseDuration during an update, it means descendants were memoized and skipped. When the two values are close, it signals that many components re-rendered even though their props or state may not have changed, indicating missing memoization or unstable references. Fourth, you would aggregate these measurements across interactions to pinpoint which subtrees consistently show high actualDuration relative to baseDuration.

COMMON WRONG ANSWERS: A common mistake is describing only the React DevTools browser extension flamegraph without mentioning the programmatic Profiler API or the specific timing metrics. Another red flag is suggesting that you should add console logs inside render methods to detect re-renders; this is imprecise and does not give you timing cost. Candidates also err by ignoring the phase parameter and treating mount data as evidence of unnecessary updates, or by suggesting profiling in production without acknowledging that profiling is disabled in production builds by default and requires a special build to opt in.

LIKELY FOLLOW-UPS: The interviewer might ask how you would automate this profiling in a continuous integration pipeline, or how you would reduce overhead once you identify a slow subtree. They might also ask what the difference is between actualDuration and baseDuration in concrete terms, or how you would use multiple Profiler wrappers to isolate different parts of the application such as a sidebar versus a main content area.

ONE CONCRETE EXAMPLE: Suppose you suspect a list component is re-rendering too often. You wrap it in Profiler with id set to ProductList and implement onRender. During a search interaction, onRender fires with phase update, actualDuration 12 milliseconds, and baseDuration 110 milliseconds. Because actualDuration is much smaller than baseDuration, you conclude memoization is working and the list is not the bottleneck. Later, you wrap a header component and see phase update with actualDuration 45 milliseconds and baseDuration 48 milliseconds. The values are nearly identical, so you inspect the header and discover it receives a new object reference on every parent render, causing it to re-render unnecessarily. You fix it by memoizing the object with useMemo.