The shouldComponentUpdate() life cycle method enables macro-optimization of your component performance. If there's clearly no need to re-render the element, then let's sidestep the reconciliation process entirely. Other times, reconciliation simply cannot be avoided—the element state is changing frequently, and these changes need to be reflected in the DOM for the user to see.

The development version of React 16 has some handy performance tooling built into it. It calls the relevant browser dev tool APIs in order to record relevant metrics while a profile is being recorded. Note that this isn't related to the React Developer Tools browser extension that you installed earlier; this is simply React interacting with the browser when in development mode.

The aim is to produce React-specific timing data so that you don't have to mentally map 20 other browser performance metrics to your component and figure out what they all mean. Everything is there for you.

To demonstrate this functionality, you can use the same code from the previous section with a couple of minor adjustments. First, let's make more members available in each group:

state = { 
  groupCount: 1, 
  memberCount: 200, 
  groups: [] 
}; 

The reason we've increased this number is so that the performance of the app degrades as you fiddle with controls—it's this performance degradation that you want to capture using performance dev tools. Next, let's increase the maximum slider value for the members field:

<div className="Field"> 
  <label htmlFor="members">Members</label> 
  <input 
    id="members" 
    type="range" 
    value={this.state.memberCount}
    min="1" 
    max="200" 
    onChange={this.onMemberCountChange} 
  /> 
</div> 

That's it. Now when you view this app in your browser, it should look like this:

Before changing any of these slider values, make sure that your developer tools pane is open and that the Performance tab is selected:

Next, click on the circle icon to the left to start recording a performance profile. The button will change to red and you'll see a status dialog appear, indicating that profiling has started:

Now that you're recording, slide the Groups slider all the way to the right. As you get closer to the right, you might notice some lag in the UI, which is a good thing since this is what you're trying to engineer. Once you reach the right side of the slider, stop the recording by clicking on the red circle that you clicked on to start the recording. You should see something similar to the following:

I've expanded the User Timing label on the left because this is where all of the React-specific timings are displayed. Time flows from left to right in this graph. The wider something is, the longer it took to happen. You might notice that the performance worsens as you near the right-hand side of the slider (and this might also coincide with the lag you noticed in the slider control).

So, let's explore what some of this data means. We'll look at data on the far right since this is where performance really dropped off:

This label tells you that the React Tree Reconciliation took 78 milliseconds to perform. Not terribly slow, but slow enough that it had a tangible impact on user experience. As you move your way down through these labels, you should be able to get a better idea of why the reconciliation process takes as long as it does. Let's look at the next one:

This is interesting: the App [update] label is telling you that a state update in the App component took 78 milliseconds. At this point, you know that a state update in App caused the React reconciliation process to take 78 milliseconds. Let's jump down to the next level. At this level, there are two colors. Let's see what the yellow represents:

By hovering over one of the yellow slices, you can see that Group [update] took 7.7 milliseconds to update a Group component. This is a tiny amount of time that probably can't be improved upon in any meaningful way. However, take a look at the number of yellow slices representing Group updates. All of these slices of single-digit timings add up to a significant portion of the overall reconciliation time. Lastly, let's look at the brown color:

This label, Group [mount], indicates that it took 6.5 milliseconds to mount a new Group component. Once again, this is a small number, but there are several slices of them.

At this point, you've drilled all the way down to the bottom of the component hierarchy to examine what's causing your performance issues. What's the takeaway here? You determined that the bulk of the time taken by React to perform reconciliation is happening in the Group component. Each time it renders a Group component, it only takes single-digit milliseconds to complete, but there are a lot of groups.

Thanks to the performance graph in the browser developer tools, you now know that there's nothing to gain by changing your code—you're not going to improve on single-digit millisecond times in any meaningful way. In this app, the only way to fix the lag that you felt as you moved the slider toward the right is to somehow reduce the number of elements that get rendered on the page. On the other hand, you might notice that some of these React performance metrics have 50 milliseconds, or hundreds of milliseconds in some cases. You can easily fix your code to provide a better user experience. The key is that you'll never know what actually makes a difference without a performance dev tool like the one you've worked with in this section.

You can often feel the performance issues when you interact with your application as a user. But another way to verify that your components have performance woes is to look at the frame rate that is displayed just above the React metrics in green. It shows you how long frames took to render during the corresponding React code below. This example that you've just built starts off at 40 frames per second when the slider is to the left but ends at 10 frames per second when the slider makes it all the way to the right.