Measuring Performance

[00:00:00]
>> Jon Kuperman: Performance, who's excited for this one? It's my favorite one. Okay, cool, so the Performance tab is usually the one that I think scares away the most people. And I actually think it's quite nice that instead of just showing you the button to click, they've added some nice UI over the recent months to it.

[00:00:15]
I believe in an attempt to make it less scary seeming when you go to it. Basically, these are just showing those exact same web core vitals, remember, that we talked about at the beginning. So if I go ahead and I refresh the page with it open, it'll show me the largest contentful paint, cumulative layout shift, which is 0.

[00:00:32]
And then if I interact, like hover or scroll, let's say, we can get this interaction to next paint. Those aren't really what we're here for, but it's a nice, gentle introduction, got the Performance tab open. It's not so bad. So this page does not do much. It doesn't have any JavaScript, just the CSS.

[00:00:49]
So let's go ahead and we'll just hit record. We'll scroll up and down a bit, and then we'll just stop the recording. Okay, so there's a lot to kind of talk about here. We'll try to keep it simple for this first pass. I think for now, we can kind of hide this bottom area.

[00:01:06]
This is gonna be specific when we're clicking on things, and we can kind of just focus on this general area here. So they have changed us a lot over the years. I think if you had taken my last course, which was not that long ago, the Performance tab would look quite different.

[00:01:21]
That being said, all the same information is here, they're just trying to make it I think a little bit easier to digest. Especially as things like multi-threaded JavaScript with workers and things like that, and more animations on sites. As those things kinda come in, I think that they have deserved their own section, and therefore, the graph has gotten a little bit more complicated looking.

[00:01:41]
So the thing that we'll do most of the time is that we will just focus on the main thread. So really, what you're gonna probably be doing most of the time is you're opening, you're running the performance audit, and you wanna see just what the main thread is doing.

[00:01:53]
Cuz that's where your JavaScript code is going to be running. It's always gonna be running in the main thread, unless you use a worker. Are people familiar sort of at a high level with this workers or multi-threaded JavaScript idea that, for the most part, for the longest time, JavaScript was single threaded, right?

[00:02:09]
So everything you did was just in this one CPU thread. And if you blocked, then it blocked everything, right? So if you were doing a loop counting to a trillion, the users couldn't click or scroll because the thread was used. And then over time, the web spec has added ways that you can toss some work off into another thread.

[00:02:28]
And the most common way of doing that is with a worker. So you can just basically think about it as being able to do work without blocking. So you can say, you count to a trillion, I'll wait for you to be done. And meanwhile, while I'm waiting, the users can use the site.

[00:02:40]
So it's really good when you're building CPU-bound applications. We do a lot of financial stuff, where numbers are coming in and calculations are happening, but we can't just block the thread forever. So multi-threaded is really, really good for that. But it comes at this kind of tooling cost, where now you need to be able to see all the different threads if you were to invoke them.

[00:02:58]
So for now, let's ignore the thread pool, cuz we're just doing our own thing. Ignore the GPU, ignore the animations, and we'll just focus on the main thread. So from here, on Mac, it's Cmd, and then zooming in and out, scrolling, on Windows, it's Ctrl and scrolling. And so you can scroll around with left and right.

[00:03:20]
And then you can zoom in and out by Ctrl or Cmd, and then scrolling up and down. And so we can kind of see the whole application, or we can pick an area and we can kinda drill in on a little bit of it. As you can see, this application is not doing very much, cuz we don't have any JavaScript.

[00:03:34]
But then if we were to zoom in on certain areas like here, we can kind of see Chrome is telling us what it's doing under the hood. So native task kicks off, and it does this Evaluate script. And so this Evaluate script is what happens when a piece of JavaScript gets loaded.

[00:03:49]
These gray events are system level things that are not caused by your code. So you can see an internal task queue or a profiling overhead. The important thing, and we'll get into this quite a bit later, is if you had a JavaScript file and it counted to 100, you would see that here, how long it took would be the width.

[00:04:08]
The depth would be the call stack. So if you had foo equals bar equals baz, your call stack. And then how long it took is just how long it actually took to process. So if it was counting to 100, it would be a small bar, and if it was counting to a million, it would be a larger bar, things like that.

[00:04:22]
And so we kind of can navigate around here, and we can see a lot of different information like as the x-axis here is time, you can see that not a lot is very busy. Whereas if we were to go ahead and open a real app like google.com that's really doing something, and we were to record that as it kind of loads and does all this stuff.

[00:04:40]
Then in the main thread, we can see it's actually doing quite a bit of things, right, quite a bit of work. And so then we can kind of zoom around and we can see that a script gets evaluated, but it also starts calling these functions, and these functions call other functions.

[00:04:52]
And we've got these big call stacks and all this kinda great information. We're gonna work today with just really simple examples, none of these big apps. So we can kinda just see, how long does a loop take, or how long does this take? But the kind of idea here being that you're exploring the main thread.

[00:05:08]
The x-axis is time, and you're kind of seeing what time is spent doing and which function. And how long it took and why it took that long, etc, etc. The last thing that I kinda wanna cover here is the color schemes. So as we're sort of browsing around, we can see a lot of these yellows and blues and things like that.

[00:05:27]
That's what this bottom key is here for. So the yellow is always scripting, time actually taken in your JavaScript application. The gray is just system stuff. Those are unavoidable, like the Chrome actual system running, rendering, loading, and painting. We'll dive into these a little bit more in the network section, but they're all kind of part of the same process.

[00:05:45]
Which is you load some code, you execute the code to figure out where things are going to be, that's rendering. And then you actually do the pixel painting on the screen. So yeah, I find it best to do a first pass at this, and then we'll come back to it.

[00:06:00]
Hopefully I didn't make anything worse than it was before. I know that there's a lot to kinda think about here, but essentially, we're sort of looking at a really big overview of what our application's doing, thread by thread. Able to see the tasks done, able to see how long they took, what functions they called, everything like that.

[00:06:18]
Does anybody have questions on just this early primer? We will get into this a lot deeper later.
>> Speaker 2: What's the layer of abstraction here versus your system? Cuz I'm seeing things like GPU and CPU. Is this only the Chrome process?
>> Jon Kuperman: Yeah, exactly. So yeah, that's a great question.

[00:06:31]
So if you were to run something like SISD or whatever on the thing, you would get a lot deeper information. So I think, yeah, the barrier here is that it shows you granular information up until the first level of the Chrome process. And then everything deeper is just marked in gray as task or system or something like that.

[00:06:49]
So you won't be seeing any operating system, kernel level, none of that stuff. The lowest that you will see is, okay, Chrome had a testifier, or Chrome had a loop that it was doing, or Chrome has cleanup. That's the lowest level that you'll see. Everything that's your code, you'll see in pure fine grain.

[00:07:08]
You'll see each function that you called and how long it took.
>> Speaker 3: What's the difference between total time and self time?
>> Jon Kuperman: Yes, that's a great question, total time and self time. So when you think about functions, let's kinda forget about all this complexity here. And we'll think about, you have a function foo, and all it does is it calls bar, and then bar counts to a trillion, okay?

[00:07:27]
So they're very different. So foo calls bar, bar counts to a trillion, let's say that takes ten seconds. I'm just spitballing here, I have no idea how long that would take. So bar counting to a trillion, its self time and total time will be ten seconds. Self time being how long it took to finish, total time being how long it and all of its children took to finish.

[00:07:48]
Bar doesn't have any children, so its self time and its total time will always be identical. Foo will have a really small self time, cuz it did almost nothing. All it did was it called bar. But its total time will still be ten seconds, because that's how long it took for it and all of its children to finish.

[00:08:02]
And this is kind of important because when you're digging into real applications, you don't really care about what had the largest total time. The largest total time will always be the top of your call stack, right, the first function. What you really wanna look at is what had the largest self time or the last thing with a large self time.

[00:08:20]
I always view this as when you're looking down these call stacks, whatever app it is, what you really wanna focus on is the last wide one, right? So you'll see wide, wide, wide, tons of little narrow ones. And what you really care about is this last, the lowest, down wide one, because that is the thing that had a large self time but none of its children had a large self time.

[00:08:41]
So you're like, okay, something about you is slow. It's not that you just happen to call something slow, like this one. I know these are bad examples cuz they're not named, but this one I'm not so worried about because it called this slow child. This one I'm a lot more worried about because it doesn't really have a slow child.

[00:08:55]
Something about it took a long time.
>> Speaker 4: When you have some website based on WebGL or Three.js, GPU can help you to do something?
>> Jon Kuperman: That's a great question. Yes, absolutely. So yeah, if you're doing anything GPU-heavy, like if you have a game or Three.js, WebGL, anything like that, which is very common, then your main thread might not be all that busy.

[00:09:18]
It's just kind of setting up things and calling functions. But the GPU thread itself, which we can see down here, will actually be doing probably a tremendous amount of work. So you can kind of zoom in to the GPU thread here, and you'll actually see your function calls there, how long they took.

[00:09:33]
So yeah, that's a great question. This is true too if you just have a really fancy splash page with a bunch of CSS transforms and things like that. You've kicked off all the work to the GPU, but you still wanna know what the GPU is doing. Yeah, that's a great question.