On-Page Performance

[00:00:00]
>> This is the on-page performance or the CPU lesson, and so we're gonna be messing with the performance panel. We're gonna learn about how to read the flame graph, how to find page jank, we're gonna learn about a bunch of really cool little tools that it has to kind of help out along the way.

[00:00:19]
And before we get into that, I kinda wanted to talk about the way that we're viewing performance these days, so Google has this rail philosophy which I really like. It's the rail performance philosophy, and it's kind of four different things to think about, four different considerations. One is general app response time, so that would be, we've all been there, right?

[00:00:40]
Where we met on a website and we click a button and it doesn't interact in any way, I have no idea, what did it get my clicked and not get my click, these kind of things. So some type of response really quick for the user, so they know that you've received what they've done, the second category is animations.

[00:00:57]
So whether it's a cool scroll animation, or something moving, or something really vital you're making a game or whatever, animation speed is really important especially cuz it gets really choppy. Idle time too, I'm sure you've all heard or people say this a lot, but JavaScript is single threaded, we're not going into too much JavaScript detail, basically it can't do multiple things at once.

[00:01:24]
And so what we often do in our application code is we just, send it I need to do this and this and this. I have all these ideas of stuff I wanna do and we just in a big file, just do all this stuff, but if you keep the thread really busy, it's hard for your app to be interactive, right?

[00:01:41]
Your app is not interactive when the thread is busy and so, making sure that you batch up your work, which we'll cover a little bit. You can go a long way with making it so, I don't know if you've been there before, been on a mobile site and it's loading you try to scroll it.

[00:01:53]
And you can't even scroll it, cuz everything is so clogged up it's so busy you can't even move it? That's what idle time is, and last one is load, so both the on page load, we covered with the network stuff, but also as you're changing things up, make sure the loading time is smooth.

[00:02:08]
And Google's kind of broken it down in this cool way, so the zero to 16 millisecond, which is really, really small, everything feels really good to a user. Once you get 60 to 100 milliseconds, users can actually, I think under 100 milliseconds they still can't tell the difference between immediate and 100 milliseconds or under.

[00:02:33]
As far as the way our eyes and brains perceive things, but once we get up above 100, you can immediately feel it, right? And so, I think one thing that's fine if you stick under 1,000, then it still feels like 1,000 milliseconds so one second, you still feel engaged in that task maybe.

[00:02:53]
But you're definitely feeling that there's been a change, some requests and some perceptible amount of work happening. And then kind of over 1,000, it's a problem, things are taking too long, people lose focus and then once you get over 10,000, which is 10 seconds, you can see a lot of abandonment.

[00:03:09]
So I think that the 0 to 16 is amazing, that's for our animations that should be our goal. 0 to 100 is totally fine for actions, if I click, add to cart and it takes 100 milliseconds to update the cart, totally fine it still feels good. 100 to 1,000 starts feeling, okay, maybe I asked a lot I can see that it's taking a while but it's still enough for people to keep focused, and I want you to go over that, people start losing focus a lot.

[00:03:34]
So it's basically kind of the same thing that we did with network, except this is different because they are on the page at this point. But, with a lot of these very modern single page apps, the slowest loads sometimes aren't the initial load sometimes it initially loads fast and then you click something and it takes a long time.

[00:03:51]
There's a terminology one, but I find this a really good educational terminology so, people mentioned page jank a lot on web performance talks. And it's interesting cuz it basically just means lag, or stuttering, or jittering, what the official definition is any stuttering, juddering or halting that user see as a site is not keeping up with refresh rate.

[00:04:15]
But I remember a long time ago, I would always hear about refresh rates, hertz or frames per second or whatever, and I sort of get that you want more frames per second? You don't want less frames per [LAUGH] second, but I didn't fully understand, what's going on here?

[00:04:34]
And so I got this definition that I found on the Google Docs that I really like, so it's, okay, it starts with your display refresh rate. And so, most of the devices today refresh their screens 60 times every second. And in order to always look very smooth, the screen is like hey, I'm about to refresh browser do you have anything, and the browser needs to be able to serve up a frame.

[00:04:59]
So that's you can kinda think about constantly happening, your monitor is like, hey, I need to go. What do you have in the browser cool, here's a frame and that's happening 60 times a second. And so if you do the math on that every 16.66 milliseconds, you have to have a new frame ready to go, that is how often one new frame will go out the door, and so it would be tempting to say.

[00:05:20]
So you need to never do so much work with an animation, that you don't have a new frame ready every 16 milliseconds. But the reality is there's actually, you don't get the full 16 because the browser has housekeeping work and stuff to do. So really, each animation needs a new frame to serve up in ten milliseconds, and if things get too blocked, where every 10 milliseconds, it doesn't have a frame to show.

[00:05:43]
So for example, you're just asking for a full repaint constantly in the browsers trying to get it done. It won't have one for the monitor so, it won't give one and that results in dropped frames basically, so you'll be losing frames there. And so this seems like a lot if you're not doing heavy video game animations, but it's worth thinking about even if you're just doing a cool wave of animation, or a background, or a parallax scroll or something like that.

[00:06:08]
There's all these ways that we can be pragmatic and we can try to be better about making sure that there's a frame to go every 16 or every 10 milliseconds, cool. So, think at that point, we can kinda open up and kind of peek in, just before we get into talking about jank and things like that.

[00:06:26]
I just kinda wanted to explain, how we should think about it with the rail model, and what these kind of times mean as far as losing frames. So the Performance tab, so go over and we'll click on it, and there's kind of two options here, option one is to this one where you do a refresh and that'll show you the actual creation of the page performance.

[00:06:48]
And option two, is just to start a Recording where you can do whatever you want, interact with something and then hit Stop, and those are for different use cases, right? One you wanna know, especially if you have a react or angular app, how does it assemble the app.

[00:07:01]
What's the page performance like when it's bootstrapping, the other one is man this add to cart button takes a long time what's going on here? And so, if we do one here a Refresh and Profile and then hit Stop, we can kind of see all these different things happening.

[00:07:15]
So, the screen is always for sure the scariest cuz there's just so much happening, but I wanna try really hard today to make it a little bit less scary, a little bit more understandable. So, I think if we view it in sections, that's one of the best ways we can do it, so I'm gonna try to kinda minimize, toggle up a couple of things here, okay?

[00:07:34]
So we sorta have three sections, we have this summary view down here, which I'm gonna minimize I'm gonna get to that one last. Then we have up here, this is a section I know it's a little bit hard to see my mouse, but above my mouse. And up here is a separate section, and that's showing three things layered on top of each other, one of them is the frames per second.

[00:07:57]
So we'll be looking for big jumps in that if we lose frames, the other one is what the CPU spends its time doing. We'll see a bunch of different colors in there, which will relate to the summary section, and then the third one is just network traffic, and so that's one thing.

[00:08:13]
So if you ignore all of these, and we just focus on this top thing, we can kind of, I'm gonna click here and I'm gonna drag an area to kind of Zoom in and focus on it. So I click and drag there, so we can kind of see that there's three different things going on, you can see across the bottom that the network is busy the whole time is our site's loading.

[00:08:31]
It's doing stuff with this blue bar, you can even see right here, it stops being busy, as soon as everything is loaded there's no more blue bar. You can also see that there's two little seconds where we actually go up in high frames per second, there's two little jumps here, right one here and one here.

[00:08:47]
And for the most part it's completely clear, and those frames per second jumps, tie in very nicely to the CPU doing work, and that's almost always going to be the case, right? The CPU is telling the browser to re-render stuff and you'll see stuff at the same time, and then the last part for this section is the colors.

[00:09:06]
So if we zoom in even closer here, we can see there it might even be a little hard to see. Unfortunately I can't make this bigger but there's yellow, purple and green, then mostly yellow, little purple and a tiny bit of green. And if we go back to the Summary tab, we can kind of see what the colors mean, so the color yellow is script running.

[00:09:24]
So if you had a for loop or Fibonacci generator, some JavaScript that's running, blue is network, so we don't see any blue that would be waiting on something to load. And then we get into rendering and then repainting, and so the rendering is heavy math that the browser is doing calculating.

[00:09:40]
If you say this needs to be 200 px by 200 px and float left, then the browser has to figure out how to size it and where to put it. And then once it's figured that out, then the browser actually repaints that area of the screen so, I'm gonna take a little pause there.

[00:09:54]
So we haven't gotten into the the big middle area, but we've looked a little bit at, okay. So we can reload or we can Record while we're doing stuff, and we get these kind of three sections up here, showing the frames per second. What work the CPU is doing and the network traffic, how are people feeling about that so far?

[00:10:13]
I know this is for years I just ignored this tab because it was too overwhelming for me so, if you're feeling pretty good about that, then you can see we did a refresh. And the page starts loading all this network stuff, you can even see back here it was just doing system work.

[00:10:29]
Something the browser's doing as refresh happens, then we get into here and you can see, okay, now some work happens. There's some scripts running, frames per second shoot up a little bit, there's some rendering and painting that happens, and it kinda goes back down to just hanging out.