Web Performance Metrics

[00:00:00]
>> Jon Kuperman: So let's talk a little bit about how we measure performance. So who here has heard of the Core Web Vitals, this kind of idea of Google? They've had a few different iterations on this, right? So they originally they had their page speed test, and page speed would measure a few different things.

[00:00:17]
And then they ended up coming up with Lighthouse, which we'll cover pretty in-depth during this course. But they basically are trying to think of these things, they also have the RAIL model, which we'll cover briefly in this course. And now they've sort of settled on these Core Web Vitals.

[00:00:30]
So Core Web Vitals, this is open source, it's under the What Working group, and lots of different companies contribute to them. And they're basically these concepts that are important to all websites and web applications. So one that you may have heard of is the largest contentful paint. And really what that means is that they monitor how your website loads, and they find the biggest paint with content in it.

[00:00:53]
Painting, for those unfamiliar, is one of the steps that a web browser does. So if you are building a web browser, and again, we'll cover this more, but you have the network layer, it fetches HTML and CSS and JavaScript, and then you have the parser and compiler. And then eventually you make this document object model.

[00:01:10]
And you do this rendering phase where you're like, well, how big is that square, how big is this square? And then, eventually, you do painting. Now that you have all the data, you tell the browser what pixels to turn what colors, things like that. And so the idea with the LCP, your largest contentful paint, is it monitors your page loading, it finds the biggest block that has some kind of content in it, and it sees how long it took for that to finish painting.

[00:01:32]
So you could think about it like if you have a shopping cart and you've got your sidebar and your header, and then you've got the items in your shopping cart or whatever, very likely the items in your shopping cart will be the largest block on the screen. And so, basically, what this is gonna measure is when that finishes rendering.

[00:01:48]
So even if you have an incredibly fast header and an incredibly fast sidebar, and then it takes five to seven seconds to load in all that shopping cart, you'll end up getting the LCP of that five to seven seconds. And so this is a really cool metric for basically kind of being able to understand how long your website really takes to load.

[00:02:06]
Not how long the first element takes to show up, or necessarily, how long the last element takes to show up. Cuz maybe the last element is an ad, and you don't really care about when that loads. But you really do care about this thing. Similarly, we've got this interaction to next paint.

[00:02:21]
Again, these are meant to be these kind of core philosophical, important bits of all web pages. So if somebody interacts, like clicks a button, like add to cart, or search, or whatever it is, how long does it take until the next paint finishes? So if I click add to cart and a little spinner shows up for seven seconds, and then eventually it takes me to a new page, that seven seconds is gonna be from the click interaction to the next major paint.

[00:02:47]
And then the last one is this cumulative layout shift. It's essentially back to this kind of way that browsers render. But it's basically like, how stable is your UI as you're kind of doing things and moving things around? And we've all probably seen these pages where the page loads, and then an image comes in, and the image throws off everything on the page.

[00:03:06]
So that would be a very low or a very poor cumulative layout shift, where the layout is changing in a big way while the page itself is loading. So we kinda wanna know, on a page load, when is the page stable, when is it really settled and shifts are.

[00:03:19]
And so this is really cool technology, this is not specific to Google. These are things that we will see when we run our Lighthouse audits. I think they're really good metrics to have. And if you are interested in them, there's really cool standards bodies and working groups behind them, yeah, to kind of just understand, yeah, how to measure performance.

[00:03:39]
>> Speaker 2: And just to add to that, Todd Gardner has a course on Frontend Masters covering web performance fundamentals.
>> Jon Kuperman: Excellent.
>> Speaker 2: That dives really deep in those two.
>> Jon Kuperman: That is great to hear, yeah. So I think these are really cool concepts. I like the direction that they're heading in very much.

[00:03:54]
And I like that the group themselves are open to adding new metrics. Yeah, and I think they're a very, very cool project to work on. Speaking of, quick last shout out to my company. So we contribute to the Core Vitals, which is really cool. So we basically have wanted for years the ability to say, I don't really care about the largest contentful paint.

[00:04:17]
What I really want is to be able to target an element, and I want to know when that thing paints, that's the important thing to me. So you could imagine financial data, you don't really care about the header or the share button or the statuses or whatever, you really care about that table of financial data.

[00:04:31]
And you want to be able to put an ID, let's say, on that table, and measure forever, how long does that table take to load data? And so over the last few years, we've been working to get what we're calling element timing or container timing. And so those will both be now added to the Lighthouse Core Vitals.

[00:04:48]
I say this much less to shout out Bloomberg, and much more to talk about how cool these things are when they move outside of a company and become an open standard that anybody can contribute to. So when you are using Lighthouse, if you, say, you set it up with CI, and eventually you're like, it'd be really cool if we had this, don't let that dream be a dream.

[00:05:07]
These are very great welcoming groups that you can join, and you can pitch anything, any gaps that are missing. So yeah, so I'm a big fan of these Core Vitals. I think it's gone through many iterations, and I'm quite happy with what we've kind of landed on here.

[00:05:21]
Cool, another one, just kind of covering up. This has not necessarily been replaced by Core Web Vitals, but it's just another framework that Google's put out, which is just a way to think about performance. And it really affects their tooling and how their tools work, but they basically think about these four different characteristics.

[00:05:38]
One of them is how responsive your app is, right? So if you click, or if you scroll, or if you zoom, or something like that, how quickly does your app respond to events? Another one is animations, what is animated, how smooth is it, how fast is it? Just generally thinking about animation across your site.

[00:05:58]
Another one is idle time, so have we all seen this thing before where we click a button, but the website's doing something? And so your button click doesn't get registered for a long amount of time? So your app should be idle, not the whole time, but it should have breaks of being idle very frequently so that people can interact with it.

[00:06:16]
It shouldn't just be hanging and thread locked for so long that people can't actually use the site. And then the last one is load, how long does a page take to load? How long does an action take to load, things like that. So again, these aren't hyper technical, they're more philosophical ideas.

[00:06:29]
But they really influence the tools that we're gonna be covering today. Okay, so I do like to do a little bit before we kind of dive too deep into the course, kind of wondering where everyone's at with DevTools. Yeah, go ahead.
>> Speaker 3: Is it reasonable to try to measure the Core Vitals automatically for all or a sample of users and collect them as metric data?

[00:06:48]
>> Jon Kuperman: Yeah, that is a fantastic question. Yeah, so this is what we call real user data, or real user performance. I do cover it later, but I think it's such a great question. So again, back to the kind of metaphor I gave, or the example I gave about measuring things on your really fast network, on your really fast computer.

[00:07:05]
Probably within a few miles of the data center that you use itself, you can measure all these things for you, right? You can open Lighthouse, you can run your app, and then you can write down how long these metrics took. But the real thing that you should be going towards if you are going to have a very monitored for performance website is, you want to know how long it actually took your real users, on an average, to load these things.

[00:07:27]
So the question being, can you collect and measure these things for some subset or actual users over time? Absolutely, you can, there is lots of open source or SaaS tools, I think, like New Relic and Sentry. And there's all these monitoring tools, there's like a million of them.

[00:07:43]
Those are really, really great, you can enable them for all users, or you can enable them for subsets. And you can really collect all these things, so you can get the P99 for largest contentful paint done, your average user. Yeah, great question. I think that as performance gets more and more important, you should have some way of measuring real user load, and that's a great way of doing it.