Profile React Components with the Devtools Profiler
The React team has given us an awesome tool that we can add to our browser dev tools to profile our components. "Profiling" basically means gathering stats on how long our components take to render and when they render. Stats are taken on all of our components and laid out in different views so we can dive deeper and find the components that we need to optimize.
Instructor: [0:00] First things first, make sure that you have the React Developer Tools Chrome extension installed inside of your Chrome browser. That is, if you're using Chrome. If not, check your other browser extension library to see if you can add this to it.
[0:14] You'll know that it is installed when you see it's right here inside of your tabs. Then, you can also check your DevTools, and you'll notice this component's in profile option.
[0:24] Right now, as you can see by this red here and by clicking on the React Tools, it says that I'm running the development build of React. I can use the Profile tab, record a session, and look at my components.
[0:37] Though, this being in development mode, I'm not going to get the true user use case that I'm going to be looking for, because as you probably know, the development mode is a much larger build, there's less minifications, and your components might not be referenced correctly in this development mode. Ideally, you want to set up your code to profile your components in a production build.
[1:02] A couple things for that. If you're working with create React app, then you're going to be in good shape because if you're using React scripts greater than 3.2., then you can simply run NPX React scripts build --profile.
[1:19] That's going to do everything that you need to do to have a production build in profile mode set up for you. However, for myself, I'm working with an ejected create React dev, so I'm going to need to do a little bit of tweaking.
[1:32] First things first is go to the alias section of your Webpack. It's going to be something that looks like this. You're going to want to add some type of Boolean check for if your build is in production or development mode.
[1:50] If it's in production, then you're going to want to alias all React Doms and scheduler/tracing to be the React Dom scheduler/profiling and /tracer profiling. This is going to add some bytes to your total build and production.
[2:07] You're going to be able to use the profiling inside of a production build to give you the most accurate representation of your application. Then also check inside of your Webpack config file if you're working with the Terser plug-in.
[2:22] We want to enable class names to show instead of our production build. Instead of the default undefined in false for when you new up this plug-in, go ahead and make sure that both of these are set to true.
[2:39] This is going to give you the actual component names of your component, which makes the world of a difference when debugging versus the one single character or two character that the plug-in will try to do to make your code as small as possible. Perfect.
[2:56] Once you have those configuration setup, we can run this build and then see what that looks like with the profile or tab. We'll say, yarn build. Perfect. Then now we can serve the build folder. I'm going to use serve here and we'll check it out on localhost:5000.
[3:19] Let's go back to here and just change this to 5,000. Now we're using the production build as you can see from our DeveloperTools over here of React. Now to take our profiling even one more step further, I'm going to go to the performance tab and settings inside of that tab.
[3:39] I'm going to throttle my CPU by six times. This is going to give me the truest representation of a experience that a user might get at the slowest level and then I can optimize from there. Everyone up from that throttling is going to have an even better experience.
[3:56] This way I can see what even the slowest network and slowest CPUs that a computer might be loading my website or application or I can see what they see. Perfect. Instead of our profiler tab here, we can click the start profiling button, which is now recording.
[4:16] We can click around our app and replicate what a user might do while on this page, like changing these buttons states, hovering, scrolling, and so on. Once we get a good idea, we can stop this and take a look at our results.
[4:32] The default view that we're going to be in is the flame graph and each bar represents a component. The bar's length shows how long it took to render the component. Example, you can see that this parent one, of course, the top which holds all the children is going to take the entire time.
[4:50] As you get smaller or lower on this page, it's going to showcase what children components took to render and give us also the names of those components as well. We'll get even more data if we actually click on these individual components on the right here.
[5:09] It'll tell us rendered at five seconds for this many milliseconds, at six for this many milliseconds. The colors are also useful here. The gray did not render during this session. Yellow, the component took a lot of time to render, so down here with this withStyles.
[5:26] Blue, the component comparatively took less time to render gray, meaning that it did not. Green being not too bad.
[5:36] This is going to be really handy to locate the components that are taking the longest time, and see if there's a way for you to optimize them. The second one here is the ring-chart, which is basically going to rank the components by their colors and by how long they took. You can see that withStyles that we saw on the flame graph is here at the top.
[5:59] Now, we can do some more stuff to this, like reload and start profiling again, clearing what we currently have profiled, loading or saving a particular profile. Then, inside of the settings, there's more here for debugging components, profiler, things like record what each component rendered while profiling, and so on.