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

The "Web Vitals" 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 compares the ways performance was measured in the past with how it is measured now. Older metrics like page load time are unreliable since they relied on JavaScript events that could be exploited. The Web Vitals are four modern metrics that can be combined to measure a website's true performance.


Transcript from the "Web Vitals" Lesson

>> So let's think about how do we translate these subjective perceived performance concepts, into actual metrics that we can care about and try and improve. Because if we stay in psychology, everything stays very squishy and hard to quantify. And so there's some ways that we measure performance in the past.

And some ways that we're gonna measure performance in the future and they're different. The old way the people measured performance is with a metric called page load. So how long from the time you clicked something until the page loaded. So in the old days, like geo cities, you'd click on it, and some of the screen would paint but it's not quite done.

And then the rest of the screen would draw and you could actually interact with it and see what kinds of things were out there. And that time from the start, from when you initially click that link or hit enter to go to that URL. Until the page was done, was yeah, was the load time.

And it was measured with the load events, which was meant to be triggered. Hey, everything is done. Here's an event. And I can measure the milliseconds between those two things and get a measure. Fortunately, soon as you start attaching value to a metric. Like a company is rewarding its employees for hitting something, or advertisers only being willing to go on to a page that loaded so fast.

Soon as you start valuing a metric, it's gonna get gamed, and the load event was gamed. Lots of techniques came around to lazy load, to like defer stuff tha don't actually paint a lot of the screen until after the load off it. The user won't notice that our load event will get a lot faster.

Well, we kind of ruined the metric when that started happening. Fact it got real bad. It got to the point where the load events on some sites would fire almost right away. Like it would be an empty screen with a blank div and the load event would fire.

And then all the JavaScript would wake up and build the page. Well, we're not measuring anything anymore, that metric has lost all its value. And so we've invented some new ways. Some new ways that are going to be harder to gain. I'm not saying that people won't hack these metrics, but they're going to be harder to break because they measure suddenly different things.

Rather than one metric that measures from the start of the page to the end of the page. We have four different metrics that measure four different aspects of performance. And these are called the core web vitals. FCP, which stands for the first contentful paint, LCP, which is the largest contentful paint.

CLS which is the Cumulative Layout Shift, and the FID, which is the First Input Delay. We're gonna talk about each of these in detail. But these metrics are alive and well and impacting your site today. Even if you have not heard of them. Google cares about these metrics right now, in your Google Webmaster Tools.

If you've been in there to like see how Google ranks your site, how they crawl your site, they're measuring your web vitals values right now. And if you cross over, their arbitrary, their not arbitrary, their thresholds. They will tell you, they'll say, hey, these things are problems and in the future, we're gonna reduce your rank if you don't fix them.

This particular site has both an LCP issue and a CLS issue. And saying hey, you got some things to fix here. So let's dig in and understand what each of these metrics mean. The first contentful paint. This is the time from the start, when the user first clicks the link or enters the URL, until the first meaningful content enters the page.

It's not a blank div, it's something was rendered. It's the header bar on MPR data. It's the first link, the title of the site, whatever. This is the time that you take until you can render the first bit of content. The time untill the user sees an indication that the page is loaded.

If we tie this back to psychology, this is when the user first feels their sense of certainty. That that click registered and that your site is online and that they will get the data there after. Before that, there's a lot of uncertainty. And the longer that goes with the white page, the more uncertainty builds.

Condense this down to a simple rule. This is about responding quick. LCP is the largest contentful paint. So, throughout the loading cycle, different parts of your screen will draw. And we can measure how much of the screen has been drawn. And the time at which the largest percentage of the screen was rendered, is the largest contentful paint.

And this is just measured in pixel area. So each time a render cycle happens, your browser will measure hey, what's the length and width of this element that just came in and all the other elements? and here's the total area. And the time at which the largest area was rendered is the largest contentful paint.

Now this is a proxy for when does the user think that the site is almost ready. Here we can see an example on The largest contentful paint on this page is actually the images, which is very common. A lot of times your images are gonna be so big that the image becomes the largest contentful paint.

And so all three of these images kind of load at the same render cycle. And so when the primary image is drawn. And article images for the columns below. And the advertisement image render, this is LCP. And so the time until these come in is an important metric to Google.

This is the time until the user sees that most of the pages there and believes that it's either ready or almost ready. Condensing that down to a rule that means get to the point. The user came to your site for a reason. Show that reason as fast as you can.

The third metric that we're gonna talk about is cumulative layout shift, CLS. This is a little GIF that we made, that illustrates exactly what this is. You come to a page and you go to click a button, but just as you're about to click a button. Some really obnoxious thing loads in a synchronously and pushes the content down and you almost just click on an ad.

In some cases it's almost like they're trying to get you to mistakenly click on an ad. And if this happens multiple times, it gets even more frustrating. Well, this movement is called the layout shift. And the cumulative layout shift is a measurement of all the times that this happens during the lifetime of your page.

So here's the New York Times. On the top, there's a really annoying top banner image that you might have seen. That pushes the whole page down. And it's like 300 or 400 pixels, and just is super irritating. And then if that primary image takes a little while to load, that can push content out of the way as the image comes in as well.

And so the Cumulative Layout Shift, is the total shift that happened because of the top image, plus the total shift of the second image. Now this isn't a metric that just recorded once during loading is done. This is the entire lifetime of the page. So if you're asynchronously loading content over time, such as an infinite scroll list of things.

If you're injecting content and pushing other content down, you're creating lots and lots and lots of layout shifts that Google is not gonna like. And frankly users don't really like. The cumulative layout shift is the total movement distance and the impact of page elements during that entire lifetime of the document.

Simplified, don't move stuff around. Once you've shown stuff on the screen, don't move it even if other stuff loads in a synchronously later. Thinking for a second. If the cumulative layout shift is all of the shifts that happened during the entire lifetime of a document. How might this affect a client-side rendered application or react application an angular application etc.

Well, in those sort of applications, often you'll click on something, and it'll redraw a big portion of the screen to simulate a page movement. But it wasn't really a page moment. It was the same document it was before. Did that push things around as part of that click?

If so, that created a whole lot of layout shift and made your commutative layout shift score a whole lot worse. All right, the fourth and final web vital that we're gonna talk about is the first input delay. And for many, this is the hardest one to understand. Cuz it's more conceptual about what the browser needs to be doing, and not so much about what the user sees.

So let's say you see a web page load and you think it's done, the largest contentful paint has happened, and you're ready to start doing things. So CNN has loaded and you go to click on an article. Well, in order to improve their scores, they might have deferred a bunch of their work to load later after the content has happened.

And that's fine. That's a good thing to do. But think deferred so much content, so much JavaScript still needs to be run, that the browser is busy doing that when the user first clicks. There's gonna be a delay, between the time when the page looks ready, and the user interacts with it, until the time the first click handler can fire.

This isn't the time that your click handler takes. It's the time that the browser is too busy passing, and compiling your Java Script, to even fire the event is the first input delay. And so this is only measured on times when the user interacts. If the user never interacts with your page, you never even get this metric.

But when they do, this is an indication of your page is ready. The user thought they could do something, but they really couldn't cuz you weren't done yet. You were still loading abnoxious amounts of stuff in the background. The first input delay is the browser time delay between the users first click and the execution of your application code.

Simplified, don't load so much stuff. Don't load what you don't need. So let's compile those together. The first contentful paint is about responding quick. Get something out the door to the user as soon as you can. The largest contentful paint is about measuring how well you get to the point.

Show the user what they came here for as fast as you can. The commulative layout shift is a rule to don't move stuff around. If you put it on the screen, don't change where it is, as other things come in. And the first input delay measures, don't load too much stuff.

Don't put too many things on the page that it's gonna slow the browser down. Each of these metrics has a range, that Google thinks is acceptable. For LCP for example, if you can show the largest amount of content in less than two and a half seconds, Google thinks you're doing great.

If it's less than four seconds, you might need to get a little better. If you're worse than that, it thinks you suck. And it thinks that it's going to rank you slower in the future. It's got these scores for each of the metrics and it's available, on the lighthouse reports and on everything that they show you.

They're gonna colour code your stuff. In fact, in our next exercise, we're gonna take a look at that as well.

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