Measure Performance with RAIL

[00:00:00]
>> Jon Kuperman: Continuing through now with our profiling, getting into a little bit more of the scarier ones with the Performance tab. I think there's some really important concepts before we look at the graph, just to understand what the graph is showing and what we should glean from it. So I always love this picture, they put it in one of their actual blog post announcements, and I feel like I can feel the overwhelming sensation in my just when I look at all the stuff going on here.

[00:00:23]
Like a remendous amount of code and there's all these different representations of it and there's red everywhere, which is quite alarming. So I think an important first step takekaway, when you run a Performance audit and you hit stop on it and it loads up, the red is really vital imformation.

[00:00:38]
And what the red is showing you what we call we call page jank. Have people heard of this phrase before? Okay, great. So page jank is basically you can think of it as like dropped frames essentially. It means that the JavaScript logic or the CSS animation was so busy that as your monitor is refreshing, the browser is asking for new frames, this is kind of how this works on a hardware level.

[00:01:00]
And if the Thread, the main thread is too busy, then when the monitor asks for a new frame, it won't be provided in time and will drop the frame. And I have some cool ways of visualizing this with our next exercise, but whenever you see something like stuttering on the screen, like maybe you're playing a video game, and it starts like really freezing.

[00:01:17]
The reason for this is not just a general Performance issue, it's because the Thread was so busy doing computation that when the monitor asked for the next paint, it wasn't ready to give it yet. So I was like, okay, I don't have anything for you. And so Nate, maybe you're seeing a paint every four frames, as opposed to every one, and it starts getting that real.

[00:01:36]
So this is true in like all sorts of media, you know, screens have these refresh rates. They ought to get a new frame for every refresh, but if you're too busy doing work, then they don't get one, and that's what causes it. So the red is really helpful, because if you see red, it means frames are being dropped.

[00:01:51]
It means that your website is not smoothly rendering because frames are being dropped. It doesn't say why, but it means that your app is too busy for too often, that frames are being dropped. So even without reading this whole chart, seeing a bunch of red is like, okay, I know I have a problem.

[00:02:06]
I'm losing some frames here, and I think that's very valuable. So again, Chrome has this thing we talked about at the beginning, this like idea of like response animation, idle and load. And these are, like the metrics that it uses, you know, how fast the page load, how often is it idle and interactable?

[00:02:20]
How quickly does it get that way? Are the animation smooth or are they causing page jank? And how quickly does your app respond to user interaction? And the Performance page is really good for showing a lot of this stuff, or highlighting specific areas where something is going wrong.

[00:02:34]
So trying to get our heads in this Performance space, we start getting down into like really small amounts of time. And human brains and how they work and how they process information. And there's some really nice things, but there's some really bad things as well. So a nice thing is that anything under 16 milliseconds, humans essentially see as instant.

[00:02:53]
They perceive it as completely smooth. So if you have frames registering every 16 milliseconds, which is 60 frames per second, if you do the math, which is 60 hertz, which is what a lot of our monitors use. You don't need to optimize faster than that. If you have a new frame every 16 milliseconds, human beings, human minds, will not be able to perceive that is, anything other than perfectly fluid and perfectly instant.

[00:03:13]
So that's kind of what we're hoping for, is that our web page should have a frame to give every 16 milliseconds. And if it does, then anything that changes between frames will look very, very smooth, very, very instant. Once you get between that 16 and 100 milliseconds, users feel like, the result is immediate if it's an interaction, right?

[00:03:32]
So on no interaction, just viewing the web page, 16 milliseconds is what we hope for. Boom, boom, boom, new frames, new frames. But on doing an interaction, like clicking, add the card or log in, or something like that, anything under 100 milliseconds still feels instant, it feels really snappy.

[00:03:46]
The human mind will not really distinguish your site between 100 milliseconds and 10 milliseconds, all feels really good for interaction. So another rule that we try to follow is, when you have some button that changes some display, try to have a new frame ready showing the new display within 100 Milliseconds.

[00:04:01]
And then once we get out a little bit of that, this can kind of feel like a 100 to 1000 milliseconds can feel like some kind of task is progressing. You know, something's happening. You're loading, it's an acceptable thing for a lot of cases. It's unacceptable for other ones.

[00:04:16]
So like doing some big computation, you click compute, and it takes 100 to 1000 milliseconds that can be okay. As long as it comes in under a second, but it's not okay for just observing something animate on a screen, it would be too slow for that. And then once you get beyond one second, you start running into all these risks of users losing focus, and your bounce rate climbs and your retention rate drops, and you've got all these issues.

[00:04:40]
So we're sort of working with these very granular numbers, but we don't really have to remember them, because all we need to know is run the Performance audit. And if you see red, it means that we failed. We didn't deliver frames in time for what we ought to have.

[00:04:53]
And then beyond 10s, yeah, users are frustrated, I think we've all been there. So another thing to keep in mind here. So we can kind of think of like we've got this 16 milliseconds and this idea is that we want our task to be completed, or at least chunked in between them so that we can repaint the screen, so that things look really good.

[00:05:12]
So if you were counting to a trillion in a blocking loop, maybe that's okay, but maybe you would break that up into groups of a thousand. And then do a little, set timeout one in between each thousand and therefore the upward will stay interactive and stay fast. But a thing that can stink and this can bite you and we'll go over this in the perfomance tab is if an input happens during one of these idle tasks where the CPU is busy, then the input will register until it's done.

[00:05:38]
So, even if you have a button click and you measure that the button click only takes 50 milliseconds to complete, which is still well within a good range. If your CPU is like, too busy that when the click happens, it queues for a long time before it'll even start, then you can get these, like, really slow websites.

[00:05:54]
So again, this is what's really good with the Performance tab, because you can drill into the real numbers to be like when I clicked the button, how long did you stall? And then when you stop stalling, how long do you actually take to render the screen, and what's that time was that too long did that feel like a dropped frame?

[00:06:08]
I know that we are getting kind of heavy here, does anybody have any questions as we are kinda starting to get into CPU performance? Screen repaints things like that, nothing that needs to be memorized I'm thinking away.
>> Speaker 2: I'm just thinking you have to have pretty intense computation logic going on to these days in terms of performance to mess up the frame rate.

[00:06:29]
>> Jon Kuperman: Yeah, so I think that it's more of a category issue of what type of app you're building, like certain types of apps, like a game or a financial app, like you could make use of 100 percent or 100 CPU core. I mean, you really could put it to right and so those run into these traps a lot when you're doing these things that would happily greedily take, you know, a million cores of CPU.

[00:06:53]
I definitely agree, when you're building, like, single page applications, where the bigger worry is gonna be, like, page load. Like, as the page loads, how long does it take before it gets interact? But then your page idle is usually pretty good once you've got everything kinda set up.

[00:07:06]
But there are quite a few categories of apps where these are very real concerns, where if you give the CPU any time, it will fill it with some kind of task. Whether it's animating things for like a game or a video, or whether it's recalculating numbers and showing them all sorts of stuff.

[00:07:24]
So I think you're that's like a great point, and it really is like a category thing, I think a lot of apps should only use the Performance tab for their page load. Some categories of apps should really use it for their steady state, to make sure that they're but I think, yeah, a lot of apps, the page loads, we're gonna see like 90% of the work.

[00:07:40]
And then, yeah, that's great. Any other questions, comments, anything like that, feeling?
>> Speaker 3: It's from a usability design perspective, at what point should you be adding visual animations for showing the-
>> Jon Kuperman: Yeah, this is a really good question. Yeah, there's a lot of really cool stuff when, well, there's a lot of different ways that you can.

[00:07:59]
We talk about interactivity time and you can get away with so much by just quickly displaying to the user that you are working on it, right? It's so much better to quickly change your button into a loading button than for them to just like sit there waiting on the web page.

[00:08:12]
So I think you can get away with a lot by, you know, animations or like loading features. I think a lot of front-end frameworks are like moving to this where every piece liece of the UI could be discretely asynchronous and have its own custom loading message. I think again, you can over optimize, I think in the 2015 era, we went way too far, where everything was a spinner.

[00:08:32]
You'd like load the dashboard, which would be like 17 spinners, and then they'd be so I think we can go a little bit, a little bit far with it, but I think that there's a lot of magic we can do by just Technology. Because I think of the frustration, I think you can think about it when you click on a button and it doesn't depress, on the screen, you're frustrated.

[00:08:49]
You're like, I clicked you, yeah, even if you click and then you take a while to do it's like, fine, you're busy, but I'm busy too. So I think you can get, you can get away with a lot by these really quick, and there's all this cool stuff, there's what's it called?

[00:09:03]
Optimistic updates where you just assume it will work and you start kind of rendering and then if it didn't work then you can retract. There's a whole bunch of really cool information design stuff you can do but i do think that stuff is hugely beneficial. Let the user know that they like the real frustrated thing is when the Thread is locked you scroll and nothing moves like that is so frustrating.

[00:09:22]
So I think there's a lot of cool stuff you can do to move around it.
>> Speaker 3: So just as a metric is, is under 100 milliseconds kind of that start to react?
>> Jon Kuperman: Yes, I think that if you are already able to do, if something already happens under the 100 milliseconds on your app, then there's no need to add extra stuff if it takes longer, I think that's a really good place to draw the line.

[00:09:38]
Did I strike a nerve with the speed Spinners, okay, okay. [LAUGH] He says, yeah, we've all been there, yeah. So I think there's just a lot you can do.