Spotting a nested update
Every change costs two renders: the normal one and a nested update from the layout effect. That's a measurement worth having: here the width could be computed during render instead (Topic 6.2), saving a render each time.
Measure before optimising: the React DevTools Profiler records every commit and shows which components rendered, why, and for how long; the <Profiler> component reports the same data to your code; and the browser's Performance panel shows the whole picture, including layout, paint and long tasks.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 5 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Wrap a ProductGrid in a <Profiler> and log a warning whenever an update takes longer than one frame (16 ms).
A memoised Row still shows in the DevTools flame graph on every keystroke, with the reason "Props changed: (style)". What's the likely cause and fix?
Explain it without notes
Why should you measure in a production build?
What does the React DevTools Profiler show, and how does "why did this render" help?
Explain the arguments of a <Profiler>'s onRender callback.
When would you use the browser's Performance panel instead of React DevTools?
Preview
Console
Nothing logged yet.Expected console output
After mount: Tooltip:mount, Tooltip:nested-update
After one click: Tooltip:update, Tooltip:nested-update