Analyzing Results in Performance Tab

[00:00:00]
>> Todd Gardner: This is the waterfall chart and the flame chart of this page load, the one that Google Lighthouse was based of. This thing can look kind of intimidating when you first start it, because it dumps a lot of data. This is like everything you could possibly wanna know about the load of this page condensed into one screen.

[00:00:21]
So it's important to know what kind of questions you're looking to answer. On the top we have the timeline spread over the entirety of this page load. Now this page load was stupid long. We go from 0 time origin all the way to 45 seconds in, which is how long it took before everything was done and the LCP events still hadn't even fired.

[00:00:51]
So from here, we can zoom in on things. So there's these little grabby handles on either side, or we can just drag and select a particular range. And that's what's gonna make this thing way more interesting, is we can zoom in on particular ranges of data and see more and more fine grain details.

[00:01:11]
Right here, we're looking at the time range. If we mouse over this area just below the top, we can mouse over the film strip. So we're looking over the time just where FCP happens, or we go from a white screen to the first paint. And what we zoomed on here cuz everything in this page is connected, is now looking at the waterfall at this particular time.

[00:01:35]
Here's the waterfall that's going on right now. The first element is we have this request for an image, this request was blocked for a long time. We see the individual line stretching all the way back since before we're looking, this thing was blocked. It couldn't start downloading for a long time.

[00:01:54]
In fact, 3.3 seconds, it's spent queuing and connecting, like waiting to get started. And then here was time where it was waiting for content from the server. And if we scroll a little bit, we can see eventually it starts actually getting content from the server. The other things that were happening at this point in time is here's three different CSS files that were all coming down.

[00:02:17]
Now these all get highlighted here with little red angles because these are render blocking. Saying, hey, these are like high priority things that stop the screen from painting. There's some other stuff happening at the time, some fonts are starting to download. Then if we look below the waterfall, we can see a flame chart.

[00:02:37]
Now at this time range, it does, It doesn't look like anything yet. These the waterfall chart and the flame chart typically happen at very different time scales. We're looking at like a couple of milliseconds here. We go from 4,097 milliseconds to 4,197 milliseconds so this is about 100 milliseconds.

[00:03:01]
And that's a that's a normal time range that we would think about, like network transactions happening in like multiple milliseconds, 10 milliseconds, 100 milliseconds, etc. But when we're talking about processing power, we need to zoom way further in. So you can zoom in by scrolling up and down.

[00:03:19]
You can also zoom in by, if you focus up here, you can zoom in by like navigating with keystrokes.
>> Speaker 2: If I don't do that.
>> Todd Gardner: Come on so if we put the focus down here, you can use WASD for the gamers in the audience, you can navigate this kinda like you would a first-person shooter.

[00:03:44]
You can stray left and right and you can zoom in and you can zoom out, which is kinda fun way to navigate. But as we zoom in here, if we zoom in super close on this last CSS file finishing, we see the flame chart kinda take shape. Now we can see, hey, here's these tasks that are kicking off as different bits are finishing.

[00:04:06]
We see, hey, this task is done which was interpreting some of that CSS file and it parses a style sheet and renders. Se we parse a style sheet. And then, we found a bit of JavaScript. So we got to evaluate that script and compile it and that kind of stopped rendering from happening for a little bit.

[00:04:23]
And then we figured out some more and we parsed some HTML, and we found some more JavaScript, and we executed it. So we can see at very low levels, here's those Flame Charts that we were interacting with. Now we jumped in from Lighthouse strained performance so that's like a big jump.

[00:04:38]
Lighthouse is like that 10,000 foot view, your boss might've run a Lighthouse report and sent it to you before. Like it's a very consumer level performance tool. Whereas this is a very developer focused performance tool. This is letting you understand the details and we're gonna like do this a little bit more too.

[00:04:58]
There's a couple of other things I wanna show off about performance that are interesting. So, we talked about Lighthouse, we talked about the device toolbar, we talked about the networking panel and throttling, we talked about the performance panel, waterfall chart, flame chart, and CPU throttling. Under the network chart is a maybe a more simplified view of this top part here.

[00:05:25]
Is rather than just looking at what's happening at a particular time, we see an entire listing of here's all the resources that were requested over the network. We also have that same kind of waterfall concept, which is visible both at the top and at the right, but we don't have as much ability to really drill in here.

[00:05:42]
This is mainly for understanding the big network requests and how long they take, rather than the individual timings of how things are loading. We're gonna spend a lot more time in Chrome in these panels over the course of this course. But are there any specific questions that we should address before I move on?

[00:06:03]
>> Todd Gardner: Yeah.
>> Speaker 3: There's a memory tab?
>> Todd Gardner: Yes.
>> Speaker 3: Is that available in the performance observer API to see if there's like a memory leak or something?
>> Todd Gardner: It is not. You can't necessarily report very well on memory from real users. There is an API. So if we let me expand this for a second, MDN performance memory, there is a thing there.

[00:06:34]
There is a memory property that has been deprecated, and it's not in use very much anymore. It's been replaced with measure, user, agent specific memory. Now this is only implemented in Chrome, as a lot of things are, but even within that, it's very experimental. What this does is it gives you a general breakdown of what's using memory, but the data is all fuzzed.

[00:07:00]
Because it doesn't want to give you the ability to like fingerprint a user based on their memory profile. And so it's not gonna give you a whole lot of like data about like exactly how much memory is used. It's going to round it up to like big whole numbers.

[00:07:20]
So in terms of, could you get a general idea if there's a memory leak? Maybe, I haven't heard a whole lot of success stories like that. Generally, once you if you feel there's a memory leak, using the memory tab locally to kind of diagnose that is super useful.

[00:07:39]
I'm not gonna get super involved into the nitty gritty of JavaScript memory management and that sort of stuff as part of this. But that's what that would be particularly used for. Nine times out of ten the big web performance problems are not usually JavaScript. It's usually about layout, HTML, images, getting things out of the wire, doing things in the right order that sort of stuff.

[00:08:05]
If you're down to optimizing the JavaScript layer, you've gotten a lot of things right already.