This course has been updated! We now recommend you take the Introduction to Dev Tools, v3 course.

Check out a free preview of the full Mastering Chrome Developer Tools course:
The "Profiling the Main Thread" Lesson is part of the full, Mastering Chrome Developer Tools course featured in this preview video. Here's what you'd learn in this lesson:

Since JavaScript is single-threaded, it’s important to be able to identify the process running on the main thread of the application. Jon show how to navigate the main thread viewer in the Timeline panel and analyze the various call stacks being executed. Some processes, like parsing HTML, cannot be avoided or optimized. Others, like user-defined functions, may be running longer than they should and indicate a place for performance improvement.

Get Unlimited Access Now

Transcript from the "Profiling the Main Thread" Lesson

[00:00:00]
>> [MUSIC]

[00:00:03]
>> Jon Kuperman: The last thing to kinda hit on here is this section over here, so I'm gonna minimize these. A lot of this is brand new, just released, I think, at Google I/O. But the important one that's always been there is, what is the main thread doing? So with JavaScript, you're single threaded.

[00:00:22] And so it's kinda cool and important to be able to see what work is going on on your website. So this is gonna be very similar. It's almost as though you took this little pyramid thing and just turned it on its side, basically. So again, the x-axis is time.

[00:00:38] And then the y-axis is just call stack. So I think one mistake is, you don't ever wanna care about a really tall one, like this one over here. See how it's really tall? Again, I'm using Shift to scroll. That doesn't matter, cuz that's just like nested functions, which are fine, that's how it works.

[00:00:56] What you wanna look out for are really fat ones. Because those are the things that take a really long time. Some of which, again, are unavoidable. So we see the biggest one is parsing HTML. So there's nothing you can do about that, right? I mean, you could have less HTML maybe.

[00:01:11] But most likely, [LAUGH] there's a certain requirement. You need to have that text and those buttons and things like that, so don't worry about it. These Evaluate Scripts are just the same as Parse HTML. It's like parsing a JavaScript, it's unavoidable. If you include jQuery, it has to parse jQuery, right?

[00:01:29] That's how that works. What you'd wanna watch out for is, you'll start seeing your own function names being really fat. Or you see update user status is taking 500 milliseconds or something like that. You're like, man, I wrote that function. Why is it taking that long? So again, the mile-high view is just looking at your widest ones and seeing what's taking so long.

[00:01:55] And then what's cool with the call stack, just kind of how you would view it is, Evaluate Script is taking a really long time. But it's not the whole script, there's something specific. And so you can go down the call stack. And the way I like to think about it is, from the fat ones, you wanna see where they'd very suddenly stopped being fat, right?

[00:02:13] So this one's huge, this one's huge, this one's huge. This one's less huge, but I think it's worth checking out. Cuz after this one, it's just like these tiny, little blocks, right? So if you've ever done anything with a profiler that's like, how long the function took and how long everything under the function took.

[00:02:34] Like cell first contained or something like that, right? It's not that the whole script took a long time to evaluate. It's specifically that this anonymous function took a long time. And then it's not just that, it's that. It's not just that, it's that. So what you're looking for is where the dropoff is.

[00:02:50] Like here, runInContext took 21 milliseconds. But then everything after it took 4, 1 ,1 ,0 ,0 ,0. So we don't really care about those little ones. We wanna see the last really wide one. That's how we're gonna kinda profile that. Does that make sense, everybody? Okay, it's a little bit confusing, but that's just kind of a rule.

[00:03:09] That's just how I look at it. I'm like, okay, I wanna drill down until there's the last wide one and then investigate it. So if we wanted to see, we parse the HTML. And then we're evaluating lodash, which is cool. This is a compiling script, we can't really do anything about that.

[00:03:25] And then the code that we could look at starts with this anonymous function and goes down eventually to this runInContext. When you click on something here, you'll start seeing information about it here, like what kind it is, right? So if you click on a purple one. Come on, Parse HTML.

[00:03:46] I guess that is it, okay. Compile Script, Evaluate Script, all that kinda stuff. So we'll see that this runInContext is a JS Frame. It took a long time. And then we can kinda click into it, if we wanted to go back into the Sources tab now, it's gonna take a second, and actually see the function.

[00:04:03] So this is the relationship you can start getting. Keep in mind, in the last little section, we talked about page audits, right? And we talked about minifying and concatenating CSS in your images and all that. Those are really big macro-optimizations, really great things that all websites should be doing.

[00:04:22] When it comes to profiling your JavaScript, that's a micro-optimization. And so what you really wanna do is, from back on the timeline, you wanna look at the whole picture. Because, let's see, this anonymous function runInContext is the biggest named function we can find. But it took 21 milliseconds, which is not a human eye perceivable amount of time.

[00:04:46] So I probably don't need to, I don't need to optimize JavaScript performance on this site, right? Because everything's actually pretty small. I'm showing you how to do it for the sake of the class. But you don't necessarily wanna like, wow, that one function's really wide. I need to fix it, or something like that.

[00:05:02] That's not necessarily a healthy attitude, because sometimes they're just really fast. It just happens to be the slowest of your really fast site. So I just wanted to point out to always keep in mind that, once you get to this screen, this is really micro-optimizations and they're really relative.

[00:05:15] So look at how long they take. If it's taking half a second to run a function, that's a problem. You wanna look into it. If it's taking, like in this case, 21 milliseconds, that's really fast. I really don't need to look at that. So yeah, just wanted to point that out.

[00:05:32] Cool, so yeah, that was starting to get used to the timeline tab. A cool feature they just added, very similar to the device emulator. Where you can see what it would look like on a mobile device. You can now do CPU throttling. So you can actually do, with the Network tab, you can throttle your network conditions to 3G.

[00:05:55] Then you come over to the Timeline tab and throttle your CPU to what it's like on a low-end device. And you can start seeing how long things take. So again, maybe that would be a better. Maybe if you were worried about JavaScript performance, you could throttle it down to a low-end device.

[00:06:08] And see how long these things are really taking. Are they taking three seconds for something to run? That's a problem. Are they still kinda fast, like in the one second range? It's probably okay.