Introducing a new React profiler

[bvaughn]

Introducing a new React profiler

Today we are releasing a new profiling tool (called the “scheduling profiler”) to open source. This post introduces some of the profiler’s features and our thinking behind them.

What is React working on?

React’s previous Profiler primarily reports how fast (or slow) components are when rendering. It didn’t provide an overview of what React is doing (the actual cooperative scheduling bits). The new profiler does. It shows when components schedule state updates and when React works on them. It also shows how React categorizes and prioritizing what it works on.

Here’s a profile for a simple app that uses only the legacy (synchronous) ReactDOM.render API. The profiler shows that all of the work scheduled and rendered by this app is done at synchronous priority:

Legacy-render-uses-the-synchronous-lane.mp4

Here’s a more interesting profile for an app that’s rendered at default priority using the new createRoot API, then updates synchronously in response to an “input” event to manage a "controlled component":

Controlled-inputs-render-synchronously.mp4

Here’s part of a profile showing an idle app (no JavaScript running). In this case, React does some pre-rendering work for components that are “offscreen” (not currently displayed).

Offscreen-work-prerendered-during-idle.mp4

Note that “offscreen” refers to a new API and set of features that we haven’t talked about much yet except for some passing references. We’ll talk more about it in future posts.

What are “transitions” and how do they work?

We recently shared an update about the new startTransition API. This API helps apps feel responsive even when there are large updates by splitting the work into (1) a quick update to show that the app has received some input and (2) a slower update (the “transition”) that actually does any heavy lifting needed as a result of the input.

Here is an example profile that uses the transition API. First React renders a small update that shows the user some visual feedback (like updating a controlled component or showing an inline loading indicator). Then it renders a larger update that, in this case, computes some expensive value.

Render-heavy-cpu-work-as-a-transition.mp4

How does Suspense impact rendering performance?

You may have heard mention of “suspense” in past talks or seen it referenced in our docs. Although full support for data fetching via Suspense is expected to be released sometime after React 18.0, you can use Suspense today for things like lazy-loading React components. The new profiler shows when components suspend during render and how that impacts overall rendering performance.

Here’s an example profile that suspends during the initial render to lazy-load a component using React.lazy. While this component is loading, React shows a “fallback“ (placeholder UI). Once the component finishes loading, React retries the render and commits the final UI.

Suspend-during-mount-to-lazy-load-component.mp4

We plan to expand support for Suspense in the coming weeks to more explicitly show when suspense fallbacks are rendered and which subsequent renders are related to an initial update that suspended.

What else might cause a render to get delayed?

Suspense can cause a render to get delayed as React waits for data to load, but React can also get stuck waiting on a lot of JavaScript to run.

React profiling tools have previously focused on only reporting what React (or React components) are doing, but any JavaScript the browser runs affects performance. The new profiler shows non-React JavaScript as well, making it easy to see when it delays React from rendering.

Rendering-blocked-by-other-JavaScript.mp4

What can you do to improve performance?

Until now, DevTools (and the Profiler) has provided information without commentary. The new profiler takes a more active approach– highlighting where we think performance can be improved and providing suggestions.

For example, suspending during an update is generally a bad user experience because it causes previously shown components to be unmounted (hidden) so the fallback can be shown while data loads. This can be avoided using the new Transition API. If you forget to add a transition to an update that suspends, the new profiler will warn you about this:

Dont-suspend-during-an-update.mp4retry.mp4

The new profiler also warns about scheduling a long, synchronous React update inside of event handler.

Dont-schedule-long-synchronous-updates-in-event-handlers.mp4

Another thing the new profiler will warn about is long-running renders scheduled from layout effects (useLayoutEffect or componentDidMount/componentDidUpdate). These updates (called “nested updates”) are sometimes necessary to adjust layout before the browser paints, but they should be fast. Slow nested updates make the browser feel unresponsive.

Long-nested-updates-delay-paint.mp4

What’s next?

We’ll be adding more to the new profiler in the coming weeks, but we’d like to get your feedback on what we’ve just released. Try it out let us know what you think. Your feedback and ideas are always welcome!

Here’s how to get started:

1. Install the latest version (4.15) of React DevTools in Chrome, Firefox, or Edge.
2. Visit a website that’s built with either a development or profiling build of ReactDOM version 18 (like this Code Sandbox).
3. Open the "Performance" tab in Chrome and record some performance data.
4. Click the "Save profile..." button in Chrome to export the data.
5. Import the data into the profiler.

How-to-try-the-new-profiler-tool.mp4

Thank you!
the React DevTools team

[markerikson]

Awesome!

First question: is this data available with the <Profiler> API in some way? I have a benchmarks repo for React-Redux that I used for stress-testing when working on React-Redux v7, and I used the <Profiler> API to record timings for mounts and re-renders.

Hmm. Actually, now I'm particularly curious. I would imagine those numbers are still relevant and accessible, and any sense of the "lanes" and "layout updates" data would be separate or additional to that.

[bvaughn]

The data is currently logged as a series of User Timing API "marks" (no "measures"). The profiler processes those marks, along with other profiling data such as native "EventDispatch" entries and CPU samples to generate the profiling report. This processing step is pretty heavy and not meant to be consumed by any external source (at least for now).

We do have plans for some new (programmatic) Profiler APIs that we'll be posting about in the coming weeks, but at the current time this new profiler is a visual tool only.

[bvaughn]

Something not mentioned in the above post that may be worth pointing out explicitly:

• The new profiler currently only supports parsing profiling data exported by Chrome. (We use a fork of the speedscope project to help parse the native bits of the profile, along with some of our own logic, so we could add support for other browsers too. It's just work that would need to be done that hasn't yet.)
• React Native isn't supported (for now) because I don't know how to collect similar performance data from Hermes. I've reached out to the RN team to talk about this.

[eps1lon]

This looks super helpful. Having screenshots right next to the profiling data will definitely come in handy.

Especially the "a huge update was scheduled during layout" should help unlocking performance benefits of React 18. Though I wonder if we could directly display a source location in addition to the component name. I originally saw this warning profining a production+profiling build and in those builds it's almost impossible to determine where this huge update was schedule.

[bvaughn]

We have plans to add both a component stack and a call stack for components that schedule updates with React, but there's some substantial refactoring that we'll probably want to tackle first. Check out facebook/react#22529 for more info.