Web Performance Fundamentals

Performance Panel Q&A

Web Performance Fundamentals

Check out a free preview of the full Web Performance Fundamentals course

The "Performance Panel Q&A" Lesson is part of the full, Web Performance Fundamentals course featured in this preview video. Here's what you'd learn in this lesson:

Todd answers questions about the performance panel. The time to interactivity metric is also discussed in this segment.


Transcript from the "Performance Panel Q&A" Lesson

>> Before we get started on part three, I wanna give an opportunity for us to talk about some questions. There was a great question in chat just before we left about whether or not the first input delay is different than another metric called time to interactivity. Time to interactivity is another metric that you'll see in the Google lighthouse report.

But it's not usually considered one of the core web vitals. It's not something that Google is gonna rank you on. They're different things. Time to interactivity is a milestone that happens sometime after largest contentful paint. And it's the milestone at which your document is all kind of built together and Google thinks it is fully ready to accept user input.

Whereas first input delay is that from the time when the user actually interacts with your site, until when your code is able to respond to an event, that delay is first input delay. The first is a milestone in the loading process. It's something else taking consider between first contentful paint, largest contentful paint, time to interactive.

Whereas first input delay is more measuring whether or not you're loading too much stuff. But it's a good question. So the question from zoom was not fully understanding what the performance and, was it the Performance tab or the Network tab?
>> It was the Performance tab.
>> The Performance tab, not fully understanding all the different information that's in the Performance tab of Google dev tools.

And well, we can absolutely do that. We'll go through that here in a second. I just wanna point out before we dig into that, that there is a whole course in the front end masters catalog that focuses on the Chrome Dev Tools and I believe it takes a deep dive into that.

But we can do a five minute version of that right now, which might be helpful for a bunch of people. So let's go ahead and do that, since I didn't see anybody else running to answer a question. So let's take a look at the Performance tab. And indeed there is a whole lot of stuff going on.

This has always been like some of the most intimidating information dense things that Chrome does, and I personally think that this could use a lot of UI work, but it is what it is. Everybody seems to be confused by it, including me. It took me a very long time of clicking around and I still get lost in it all the time.

So don't feel bad about that at all. There's a couple of different sections of this that are important. Let's go from the top down. We have this first, third of the page. Not quite third of the page. And what this is showing, is it showing kind of a top level view of how busy was your machine while this page loaded, how much of various resources were being consumed, and what did the page look like at that time.

So you can see as I kind of move my mouse left and right here, I see these little pop ups that says, at this particular time, here's what the page looked like in the loading process. Hence it's low rez, it's not like a perfect pixel perfect image, but it gives you an idea of what it was like.

So for example, this is at 1394 milliseconds 1194 994, etc. The line or this area chart in the middle, I personally have never found it valuable at all. But it's charting different things that are happening. So how busy is the CPU on your machine? And what is consuming that time?

Those numbers are the colors line up relevantly or line up to these activities here in the bottom. So if you see a blue thing coming up, it's all the CPU is caught up loading. Yellow is what you'll see more of and that's time that's caught up in scripting.

You don't see a whole lot of yellow on this particular chart because this website doesn't have a whole lot of JavaScript on it. The purple is rendering. So that's the actual time that the browser is figuring out Hey, what does this element look like? Where does it need to be, that sort of thing.

And green is painting. So the actually placing of things, the drawing of individual pixels. The top part of this which we don't really have anything interesting to say about my application, is the frames per second. So frames per second is how many, if you have an animation or something like that something is animating onto the page or you're doing fancy stuff with canvas.

How many frames per second is your browser able to render? What that is usually indicative of something much more interactive kind of thing. And you're usually shooting for 16 frames a second or better, which is what a human would be able to normally perceive of. And if anytime that frames per second drops below 16 frames per second, then the UI starts feeling a little janky, kinda like glitchy to the end user.

Again, there's no animations on this page. There's nothing really interesting to show on this particular example. And on the bottom here we have the heap. So if you're having problems with like JavaScript memory and you need to know, is there a memory leak and where it might be, this is your top little roll up of how much memory has JavaScript consumed on this page.

How much is JavaScript and the Document Object Model entirely? How much does it consume to the page and when in the lifecycle of the page during the loading process was that memory allocated? So we can see from the beginning there's very little happening right here at this point around 570 milliseconds or so.

Right here, we see a big increase in the heap. This is probably the rendering of a bunch of elements that happened because every element on the dom is like an object in the model that requires some memory. That's this high level thing rolling up here and how to read that.

This in a lot of ways is a mini map, like a navigation element to the data below, which is drilling into things. So, this middle section here is super information dense, and in a lot of ways, it's very small. And so the top is largely meant as like a navigation element.

So you see something interesting. If I see, hey, right here, there's a whole bunch of interesting things happening in this chart and it looks like a major load event is happening kinda right there, I can select this area to zoom in on it. Now this section below is now a zoomed in representation of what we see up here.

And we can explore different interactions of the page in that time. So for example, the network if we expand that, we can see what network transactions were happening during this specific time. In this case, it looks like there was a font being downloaded that was in progress from Google fonts.

If we scroll to different times, So scrolling left I see other things being downloaded earlier in the page cycle. You really need a big screen to understand a lot of this stuff. So as we scroll back, we can see all the different assets that need to be loaded as part of this page and when they started.

So if we go all the way back to the beginning, we see here's when the request for the initial document started coming in. And then at around 100 milliseconds the document finished enough so it could start downloading these other things. The main.css file started first, followed by a bunch of these images that were near the top of the DOM.

Once the main.css loaded enough it knew that it needed to start loading this other CSS files from Google. We keep going we see or at this point at 122 milliseconds, the perf JS file started loading. This must been when we hit the bottom of the page and we started rendering.

And so as we scroll through this, we can see when each resource started, and how long it took, and maybe what it was contending for resources with. Is how to read this section right here. So the network tab is, or the network section to that is super interesting.

Frames is like a zoomed in version of the screenshots, it's like when did the major parts of the page change. As you scroll through it, you'll see here's what at every different time the page change. Here's what it looked like. So at exactly this time is when the slop writing the rocket came in.

The text hasn't even rendered yet because some of the things are waiting for a font to come down. But the rocket has to come in, and the rocket is the largest thing on the page. We see a few milliseconds later, a little chat window renders, and we see the high in the corner.

And as we go through, we can see at what time did each part of the page come in. That's what the frames are showing you. Interactions and animations is for more interactive things that's like click events and how long this animation took and that sort of thing. It's not really relevant for this page.

There's nothing in it. Actually I've no idea what this experience tab is for. I've never seen anything useful in it. So I can't tell you. Main is about JavaScript. It's about execution of things. So if we zoom in on an area where JavaScript is happening and zoom in on things, we have to zoom in real far.

We can see when different tasks are being fired, so a set timeout or something is finishing and we need to do some work. Now there's nothing particularly interesting happening on this page. This must be something in the background that I don't really know about. Let's zoom out and see if there's anything else interesting.

Here's a bunch of stuff at the beginning. Right, here's a good one. Okay. So here we have some things going on and if we look at this, this is a task. If we want some more information about this, this is where this bottom section starts becoming valuable cuz if we pull this up, we can see what exactly that task was.

We can see how long did it take, what was it. It looks like it was some system task that went off executing some maybe JavaScript that's built into the browser. Not really sure. But that fired off compact evaluating a script and compiling a script. So this was probably downloading one of our JavaScript files, evaluating it and figuring out what to do with it.

And so we can zoom in here. If you have other things on the page, you probably have much more interesting JavaScript on your pages. You'll see set timeouts fire or Click events and you'll see exactly the call tree of this JavaScript called this JavaScript called this JavaScript, and how long each of those things take.

The main tab is super valuable for understanding the performance of the JavaScript itself, which was a little bit outside the sphere of this course. But there's two whole other courses in the front end masters catalog about JavaScript performance and JavaScript bundling performance, about how to get really deep on this section.

There's a bunch of other stuff that honestly I have never used for anything useful. And so I don't know that I can speak to intelligently about it if I speak intelligently at all. But so the biggest tip I can give you is think of this UI like a tree.

The top is a navigation to the middle, and the middle, blows up in more detail on the bottom. And so if you can kind of get that in your head, the information feels a little bit less dense. Also be aware that JavaScript apps are very diverse. There's lots of different kinds of things.

And so for any app that you're working with probably 75% of this data isn't relevant to you. So focus on the bits of performance that are relevant to your site. If you're not doing animation stuff, don't worry about frames per second and animation. If you're not writing a lot of JavaScript, don't put a bunch of JavaScript in here.

Focus on the bits of this that are relevant for your application.
>> So I was curious on the demonstration performance dashboard, I knew there's a lot more complex places to grab a lot of that data, do you happen to use this type of format and grabbing it for just a quick high level usage.

I know I have to deal with some sites that this could be very useful but it seems like very labor intensive but same time it provides that really nice, I don't need a lot of that in the weeds, right?
>> Yeah, so this would be, feel free to take this and use it for things.

There's a couple of kind of big limitations of this particular dashboard because this was for a demonstration kind of thing. It's not the kind of thing you would necessarily use in production. The biggest problem with this current sheet is that it's charting each individual line as its own thing when not everything is the same level of importance.

You'd probably want to roll things up and say give me a summary of what happened each minute kind of thing. So you could see variations in minute to minute. How did things happen and how many data points are rolled into each minute. You can totally do that with Google Sheets.

You could use a pivot table to do that. It's all gonna be a little labor intensive like you said. If you just need to do a one off and you had access to the data, you could totally do it. If you're gonna be doing work long term performance analysis of field data, I would totally recommend that you have some sort of monitoring aggregating solution.

Either something that you home grow yourself with something like perf JS writing to your back end and build something, or a service like request metrics or similar kind of thing to capture data and give you those long term kind of projections.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now