Inspect Performance with Dev Tools

[00:00:00]
>> There are some do not pass go, do not collect $200 if you're gonna worry about the performance of your application without at least checking these two things, right, which is one, are you running in production mode, right? And so we actually do like, local server is in development mode.

[00:00:16]
And it does things like give you console logs and yell at you about things and say, hey, you're doing this wrong and put extra things in the React DevTools, which is what we're gonna look at, and a whole slew of things like that. Again, doing stuff takes more time than not doing stuff, right?

[00:00:33]
So no not be the person who pulls down your co-worker's branch after this course. Pulls it up in development, opens up the tools like, did you see you have a 60 millisecond response time? It should be 16 because that might not actually be like that in the real app, and then you're going to have to make new friends.

[00:00:57]
And the easiest way to tell if your React application is running production mode is if you have the developer tools installed, and it's not, you'll see an angry red React icon, which is what you wanna see in development, right? Cuz you're in development mode in development. But if you go to whatever your company is dot com and you see that, it's time to tweak Webpack configs and make that not happen, right?

[00:01:23]
If you use something like create_react_app, you should get it for free, if you use most of the boiler plates, you should get it for free. I have been bitten by this because we had the bespoke Webpack configuration that someone built in 2017 and every upgrade, things happen, right?

[00:01:42]
So it's definitely worth checking that, and the remedy for that is, you just set the Webpack environment to production, right? And whatever got you accidentally in that case is gonna be different for everyone, but the solution is roughly the same. Fix it. And then the other one, which you have gotten yelled at in your console when you've forgotten them, cuz I've gotten yelled at it, and I don't think the devtool just yelled at me.

[00:02:09]
Which is if you're iterating over a list and you're mapping over a list of items to render them and you don't give each one a key, you'll get yelled at. If you give it something like the index, and we'll talk about why when we get to like a later slide.

[00:02:24]
So that React can keep track of which one is which if they get resorted or one gets removed. If you don't use keys while you're mapping over, use keys don't mean anything like the index of the array, which is literally gonna shift every time the array shifts. That is the immediate gotcha that is like, there's not a lot to say other than listen to the warning message in your console, right, and do the thing.

[00:02:47]
Those are the two easy ones that we'll kinda get out of the way. They don't have those trade offs of, if you memorize it, you could accidentally make it slower cuz the act of memoir is no, no, these are the big wins. There's no downside, just do them, right?

[00:03:04]
They work. The other thing, if you do not already have it, is to go get yourself the React Developer Tools. They are available for at least every chromium-based browser and Firefox. I don't know if they are available for Safari. It turns out I learned that you can go to the Chrome Store in Edge and install the Chrome plugin in Edge and it works.

[00:03:35]
So if you dive in React Developer Tools, you will find those. And we can take a look at those kinda for a second just to see how they work and get a sense of them, cuz I will send you on vision quests with those in a little bit.

[00:03:50]
So if you have them installed, one, you can choose whether or not you want to see this. I have done this mostly for show on a normal day, I do the hide from toolbar, I don't need to see an angry orange React icon as I'm developing but I'm here for you today.

[00:04:08]
So we've got that, and then what it does is it adds two extra tabs to your developer tools, there's profiler and there is components. Components basically gives you a component tree, which is useful, especially cuz it will give you the key, it'll let you see what is being passed or the state, you can actually tweak the state and component.

[00:04:30]
It's very good for developing. It is not necessarily super relevant for diagnosing and triaging performance issues. But you get them both together. So, okay. The one that is of more concern to us today is profiler, and profiler kinda works like the Performance tab does in Chrome or Edge or what have you.

[00:04:58]
And the kind of best way to do it is to, when you're ready, you can go and hit this Record button and do things, right, like remove a user, remove a post, add a thing, so on and so forth, right? You can make some things move around. And then usually, can you go spelunking for performance problems?

[00:05:22]
Absolutely, but it's tricky, right? Just cuz React is rendering doesn't necessarily mean that it's problematic, right? You should take advantage of the fact that I have a ridiculous laptop, right? And we'll talk a little bit in one second about how to simulate a less ridiculous laptop, right? But also understanding that the act of it rendering does not necessarily mean that you have a performance problem.

[00:05:52]
But you can kinda see this shows you basically everything that rendered, and this is kind of each interaction, right? So this is whatever the first thing that I did was, you can kinda see this is all of the rendering process. And we'll talk about what that process is and what these words mean in a slide or two, but it kinda shows you.

[00:06:14]
And the really interesting part is that not only will it show you the given components, you hover over it, what its parents was, you can kinda see all the different interactions that you did. But if you click on one of them, like on this one, you can kinda see why did this render, right?

[00:06:29]
And so to trace back what the cause of it was. If something was rendering that you didn't think should have rendered, so for instance, I know one here, so I'll hit Record. I'll hit Remove on a user. Right, and so that trigger almost everything, right? And so there are questions of, did an individual post need to post comment, right, which one of these really truly needed to.

[00:06:59]
And I can kinda figure out why did you re-render? Obviously, this is an example with known performance issues, right, or known rendering issues, at least. And you can kinda get a sense for what it was. But it's very interesting is that once you know you have a real problem, you should always start with a problem.

[00:07:13]
If you just go surreptitiously optimizing your application, one, you might be wasting your time, two, you might be causing more problems than you have, right? It usually starts with either my favorite bug report ever, which is it is slow, right? Which is both like, it's also a question I ask a lot during interviews, which is, tell me your thought process around that, cuz it's one that happens, right?

[00:07:38]
It's a way to start figuring it out, or even when you're developing a feature as you're in the middle of coding, you might notice it. So it's always important to start with a problem and then try to solve it rather than go looking for problems. I believe Rob Pike, one of the creators of the Go programming language, I believe the quote is something like measure first before you optimize performance and then even then measure again, right, to make sure, right?

[00:08:04]
And that holds true, right? Yes, we have simple apps but that does not give you a license to go and just find problems, right? Once you know you have a problem, the easiest one, the one where you know quickly is when you're typing in an input field, and the keys are not showing up in the input field as you're typing in, and I show up all at once.

[00:08:25]
That is for me the most classic one where I'm like, I have a problem here, right? Or when the browser truly locks up, right, those are the issues of when it's time to pull out the tools and jump in. But these tools are available and they're here and they give you the ability to kind of begin to dig in and look, and they're actually incredibly powerful and useful.

[00:08:46]
The other thing that you will notice if you look very closely at my screen and I use this when I know that I have a problem, right? What I actually use, personally, this is just me, subjective opinion, a lot is if you wanna hit Remove, see those green boxes flashing everywhere, right?

[00:09:07]
Those are everything that's re-rendering, right? And those will happen, I believe there's a setting actually, you can go into the tools here. Record why each component rendered, we got general. Yeah, highlight updates when components render. I would definitely go turn that on. And then whenever your developer tools are open and not when they're not open, which is both good for your general web browsing, but also you will think you have the most performant app in your world for a second until you realize you closed the developer tools.

[00:09:35]
That will happen to you at least once. Supper useful for just as you're working, everything is flashing green. Again, we were not seeking to solve problems before they exist, we're also not seeking to ignore our act of creating a problem at the same time, right, especially if it is one of the no-cost performance remedies.

[00:09:57]
For instance, we saw keys, production mode, and the one that we'll talk about at the second is either state management, or component hierarchy. Those are zero downside optimizations, while memorization some of the other ones have some cost to them. And sometimes, you always have to think about even the zero cost and performance ones, do they have complexity cost?

[00:10:18]
Cuz if they have complexity cost, then also it's like, yeah, the code is a microsecond faster now, and it takes me ten more extra minutes for a new person looking at this component to read it. I don't know that you made the best tradeoff. So we'll kinda talk about and think about those things as we go through.

[00:10:37]
The other thing I wanna point down here is choosing the regular tools under Performance. One thing that React will do once you have the tools installed if you're running in development mode is, In the regular tools, Use the user timing API to at least start to annotate some of the different.

[00:11:04]
This one doesn't have particularly slow JavaScript in it like some of the other ones do, but it will tell you what component was rendering and stuff along those lines, while it won't do that in production. So you get a little bit more extra information. But the more interesting part, cuz I usually use the other one, is if you are on a incredibly fancy MacBook Pro like I am with more RAM than I thought they could put in a computer.

[00:11:31]
You can go ahead and hit this little thing here, which is to either throttle your network or throttle your CPU, right? And a lot of times, especially depending on what you're working on, incredibly useful, cuz what might seem fast on your computer might not work unlike the average, for instance, computer on a coffee shop WiFi, right?

[00:11:55]
And so getting a sense for both of these things on a slow network connection and with a throttle CPU, right, I think is a good use of kind of having empathy for your customers, particularly, I personally work on a bunch of developer tooling, right? So I can make a few assumptions about the computers that my customers are using.

[00:12:18]
But prior to that, I worked on a consumer product, right, very different demographics. And also it's tricky because while my current customers have faster computers, they will also shame me for performance a lot faster as well. So the bar is higher, I just don't necessarily need to throttle my computer as much.

[00:12:39]
But they will show up in my GitHub issues. So, awesome. So those are the developer tools and they're super useful and we will use them throughout the day to figure out why stuff is re-rendering.