The definitive guide to profiling React applications
Knowing how to profile a React application to improve real-world performance is a good tool in any front-end developer’s toolkit. The Profiler API allows us to do just that with insights on why and how long our components are rendering for.
We can use the profiling data to find unnecessary and expensive renders that may be impacting performance negatively. Thankfully, it’s not that complicated. Let’s take a look at the Profiler API that comes bundled with every React install.
You can interact with the React Profiler API in two ways:
The React Devtools extension
The Profiler Component
Both allow you to interact with the same data, but in different ways. Whichever one you choose depends on your use case. By the end of this article, we will have covered how to use the Profiler API to measure and improve the performance of a React app.
The React Devtools extension
The Devtools profiler offers a simple, visual way of profiling a React app. We can visually see components that re-render and even pinpoint the cause of the render. Using such valuable information, we can make decisions to reduce unnecessary renders and optimize performance.
We can navigate the component tree and gain valuable insight
Let’s take a look at the interface of the profiler so that we’re able to understand the profiling data. I’ve numbered each section(in red) so that we can break it down bit by bit.
1. Component chart
This is a chart of all the components being profiled in a commit. To understand what a commit is, we have to understand how React renders a component. It does this in two phases —
The render phase where it determines what changes need to be made to e.g. the DOM. During this phase, React calls render and then compares the result to the previous render.
The commit phase is when React applies any changes.(In the case of React DOM, this is when React inserts, updates, and removes DOM nodes)
So a commit is basically all the changes applied from the render phase. A render may not always lead to a commit(i.e there are no new changes) but a commit is always from a render so you can think of a commit as a render even though they don’t exactly mean the same thing.
The component chart can display different types of information depending on the currently selected view. It can display either —
A tree of all components being rendered in the commit
A sorted view of all the components in order of slowest to fastest
In this view, we can also hover over the component bars to see information like if and why the component rendered, the duration of the render(or commit), and based on colour of the bar, whether it’s a relatively slow or fast render.
2. Tabs
Flamegraph tab — shows the component tree for the current commit. It Includes render information about each component in the tree. The length and colour of the bars indicates how long the render took.
The longer a bar is relative to the other bars, the more time it took to render
The yellower a bar is, the more time it took to render
The bluer a bar is, the less time it took to render
If the bar is grey, it didn’t render
You can also hover or click on a component bar to get information on why the component rendered(you have to enable this in the profiler settings using the gear icon before profiling)
Ranked tab — Similar to Flamegraph but sorts the components based on which took the longest time to render. The slowest components will be at the top and the fastest will be at the bottom. This makes it easy to identify which components are affecting performance the most.
It seems the Input component is taking the most time to render
Interactions tab — Shows information on how long certain UI actions take using the experimental tracing API. It can track actions like whether a specific button was clicked or whether a form was submitted. Because it is still experimental and the API is prone to change at any time, we will not be focusing on it.
3. Commits overview
This shows an overview of all the commits(renders that led to actual DOM updates) being made as the app renders. The slower a commit is(i.e the slower the render), the longer the bar will be. We can navigate back and forth between commits to get more information about a particular commit.
This is useful in instantly identifying when an app is making more commits than expected. For instance, if you type a single word in an input and there are 20 commits being made for just that action, then there’s a good chance some of those commits are unnecessary.
The React Devtools extension