On-Page Performance Profiling

[00:00:00]
>> Jon Kuperman: So let's go into the lesson together, do a little profiling, and then we'll do an exercise. Basically, what I wanna do here is I want to open up the Inspector. I wanna go to performance, and then I'm just gonna do a little recording, and then maybe I'll just kind of hover on a couple of different things, or something like that, and then I'll hit Stop.

[00:00:17]
And we'll kinda go back into this sort of scary, but getting less scary by the hour, I hope, screen here. So we can see pretty quickly, if we move this, we can see, do we have page jank? Let me just ask you that.
>> Jon Kuperman: Yes and a no.

[00:00:36]
Okay, why do you say yes?
>> Speaker 2: I say yes cuz when I was looking at it on my own.
>> Jon Kuperman: It was a little bit janky when you looked at it. Okay, so we do have a bit of these long tasks. So when you see this red, it's not a guarantee that you have page jank, but it is telling you that certain tasks took longer than that 10 or 16 milliseconds allotted, right?

[00:00:57]
So it's not necessarily a guarantee of page jank, but it is saying that, hey, look at this thing. I know it's a bit small, but this task took 18 or 0.18 milliseconds. It's this long task that took whatever it is. So we've got a little bit in there, not necessarily that we're dropping frames because if we were, then we would see the little red bars on top of these things.

[00:01:19]
So it is likely that we don't have page jank. That being said, the red is at least helping us indicate that we have long running tasks. Cool, so we can kind of see here that we've got some animations. We can kinda look down into these and kind of edit those.

[00:01:34]
We're gonna kind of avoid a lot of this stuff for now. We're really just going to stick into this sort of main thread looking at these things. So we've got these animation frames are firing. They're calling these function logs. And if we go ahead and we look and we click through to the source code here, you can see that we've got this frameLoop that runs in a requestAnimationFrame.

[00:01:54]
So what I would hope, as we sort of think about this, is even being brand new to an application, and you don't know the source code. You've not seen it before. You can kinda load it up. You can see that there might be some questionable performance, but we probably aren't dropping frames.

[00:02:08]
And then you can see that we are using probably some request animation frame, animation frame fired, and in it, we're calling a function called frameLoop. Not looking at any source code, just looking at the performance audit, we can start getting, right, some good ideas about this thing. Okay, so this app is probably calling something in a request animation frame that takes a long time.

[00:02:27]
Maybe because of that, we're not dropping frames. Does this sort of make sense, how we're kind of like thinking about things, at least taking the information kinda given to us here without knowing anything about the source code. Just sort of like putting some pieces together of how this app is running and what it probably looks like under the hood if we kinda got into it.

[00:02:44]
>> Speaker 3: Show me again how you got to the function?
>> Jon Kuperman: Yep, so just basically clicking on anywhere any of these frames here, and then you drag up this little bottom thing and it should tell you the stack trace where it came from. That'll take you back into the Sources tab.

[00:02:57]
One really cool thing that I like, kinda pro-tip thing is once you have run a performance audit and stopped it, from then on, when you go into the sources, you'll notice a new column. And what that column is is how long on average that function took to run.

[00:03:13]
It's kind of a cool thing. So it basically, decorates your source code with these little visual sections that are like, this console.log took no time, but this frameLoop, which caused an expensive operation, took 3000 milliseconds or whatever. So this will work on really large apps too, where you run the performance audit, and once that's finished, you can go back into sources.

[00:03:32]
You just start clicking on your source files, and it'll have really detailed information about how long each function took to run. Okay, yeah?
>> Speaker 4: Is there a best I guess you're on collecting your performance snapshot, just cuz mine looks a lot different than yours, I don't think I got as many of the animations.

[00:03:46]
>> Jon Kuperman: That's interesting, yeah.
>> Speaker 4: Full page, how do I know I'm getting a good.
>> Jon Kuperman: Yeah, that's a really great question. Yeah, I think there's a lot of nuance with how best to collect these things. So I guess what I would say is, when you're really looking for one, I would pop out the DevTools, I would go to Performance and clear this, I would start a profile, and then I would do a bit of interacting.

[00:04:07]
So there's a bit of a tricky balance, where you don't want too much information in there. So I usually try to keep the profile under five seconds, otherwise it's just a lot of data to process. But you do want to be doing or interacting with the site in some way to see how it performs under some amount of stress.

[00:04:22]
So yeah, I think that's a really good question. Yeah, I guess just like popping out, keeping them more than a second but under five, and trying to interact with the site a little bit as you're kinda going through it.
>> Speaker 4: What I heard is almost like a test-driven development approach.

[00:04:34]
If you wanna test one thing specifically, and then if you have a lot of things you wanna test, just test them individually.
>> Jon Kuperman: I think that's a great way of putting it, yeah, absolutely. Cuz I think you lose a lot of value as the snapshot gets too long, then you're kinda trying to zoom in on where it might go.

[00:04:48]
I know these flame charts and flame graphs can be a little bit difficult. You've got a lot of different ways to view the same data. So again, with the way that these flame group charts are working, the x-axis is time and then the y-axis is the call stack itself.

[00:05:05]
For example, we could go into that debugging one where you had the function numbered one, two, three, four and you would see it that way. So again, I know I mentioned this at the beginning, but sort of what you're often looking for is the last wide frame in a stack trace, right?

[00:05:18]
So if this is one discrete stack trace here, the thing with the self time that was a lot will be the last wide one. So yes, request animation took a while, but really its self-time is only 10 microseconds. Yes, this anonymous function took a while, but its self-time is only 0.18 micro.

[00:05:36]
So what you're really looking for is the thing with the long self-time. The function that actually took a while. And you do have a bunch of cool ways of loading this. So if you go into the bottom, you can view your stack trace in different ways. So you can view this Bottom-up approach, which will show Self time, Total time, and Activity.

[00:05:53]
And you can click into different methods. This is a lot more useful on a real application, where you could just sort, what's my slowest Self time on my whole app, or something like that. You can group things in different ways, like group them by URL or group them by types of activity, stuff like that, which is pretty cool.

[00:06:10]
You can similarly do this call tree. The call tree is like from the very top thing, what did it call and kind of explore. So again, keeping in mind these are all ways of visualizing the exact same data. It's not different data. I think that's part of what makes the Performance tab so overwhelming is that it's got sort of multiple views of the exact same data.

[00:06:29]
So you can kind of see here, even as I move around on one, that it updates the highlight on the other. It's all the same stuff, it's just for different tasks, how you might wanna look at it. You might wanna start by looking at it over time with this kind of timeline view that we have here.

[00:06:43]
Then you might say, okay, but what was really my slowest thing? So I can go to Bottom-up, sort by Self time. I can see that by far, frameLoop.js in here was my slowest actual function. So you can get kind of a better perspective on it.