Largest Contentful Paint (LCP)

[00:00:00]
>> Todd Gardner: Google's Core Web Vitals. We're gonna be on this one for a little while. The Core Web Vitals measure three things, three specific kinds of performance. One, how fast your site visibly loads to the user, not the load event, but how fast the site feels like it has loaded in terms the user viewing it.

[00:00:21]
The second thing is how smooth it loads. How smooth is the sequence of events that happens during that load. And third, how quickly can users interact with your site? And those are measured with three different metrics called the Largest Contentful Paint, or LCP, the Cumulative Layout Shift, or CLS, and Interaction to Next Paint, or INP.

[00:00:48]
Now, we're gonna go into each one of these in a lot of detail. But first, let's just talk about, so this is important again, because search ranking incorporates the core web vitals and other page experience metrics. These things are ranking factors, these things specifically. So there's other performance metrics, and they're important for various reasons, but these three we talk about a lot in web performance world and in SEO world because they are direct ranking factors.

[00:01:20]
So let's get into them. LCP, the Largest Contentful Paint, the LCP is how fast your site visibly loads the most important element, that's what it's trying to load. How fast is the most important element on your site load? Now, what's important? What's important element? Who gets to decide what the important thing is?

[00:01:44]
Do you get to tell Google like, hey, this product image is the most important thing? No, Google doesn't trust you because if you got to tell Google what the most important thing is, you'd put some little empty div at the top of the page that loads right away as the most important and you'd have super fast LCP scores, that doesn't work.

[00:02:03]
It needs to be in a way that developers can't influence this in negative ways. It needs to be about what the user sees as the important thing. And so, instead of important, we actually measure the largest. The largest thing by pixel area on the page. But wouldn't that just be the body elements?

[00:02:23]
No, there's only specific things we care about. We care about these things, we look at images, videos, CSS background images, and any DOM element that contains text. We look at all of those elements and we try and decide what the largest is. But there's some rules, because not every one of these elements, even though they exist on the page, would be visible or interesting to the user.

[00:02:49]
So there's some rules that apply to this. One is, it can't have a 0 opacity. If you've made the element transparent, it doesn't count for LCP, you can't trick it, right? Otherwise, we can take an element, make it really big, make its opacity 0, and it would always be our LCP element and we could hack the metric.

[00:03:10]
Its size needs to be smaller than the whole page. You can't just throw an element and cover the entire viewport and call that the LCP element because Google will say, that doesn't count, no, that's a background. And the third thing is that, it doesn't count for low entropy images less than 0.05.

[00:03:31]
And a lot of you should be saying right now, Todd, WTF is entropy, that is too big of a word for this class. No, it's not, because it's important for LCP, so let's talk about entropy. Here's an image, this is the hero image for developer stickers. Unencoded, this is 3.9 megabytes, which means it's 31 million bytes.

[00:03:58]
Entropy is calculated by the number of bits per visible pixel shown. So if we render this image at 2,800 by 1,200, which is the biggest it can be shown at, that means we're gonna render those 31 million bytes across 3.3 million pixels. Entropy is just dividing those, it's saying, how much data are we showing?

[00:04:24]
How much data density are we showing in this image? So, the score here is 9.39, this would qualify as an LCP image. Now, why is this important? Well, a common pattern that a lot of people will use is to use images like this. Here's a heavily blurred and down sampled version of the same image.

[00:04:46]
And unencoded, that image is 17 bytes, 17 bytes, and its dimension is really small as well. So it's only 200 by 88. And so, when we render this image, let's say we rendered this image as a placeholder, we stuck this in and then used JavaScript to replace it later, so that the user kind of felt like it wasn't as slow.

[00:05:09]
The entropy of this is 17/17,000 or 0.001, so it's very, very low entropy. There's very little visual data in this image. It's basically a blank color with a little bit of variation to it. So why is this important? Well, that image right there, if I tried to use this as a placeholder, doesn't count for LCP.

[00:05:35]
It doesn't matter when that loads, it doesn't matter how fast we made it. Google doesn't thinks that counts because the user doesn't think that counts as gonna wait for that full image to come in and would trigger the LCP event. So, this pattern doesn't act, even though it would help user experience, does not actually help you improve Largest Contentful Paint.

[00:05:59]
How do you get this information? Here's a little sample, you can actually calculate this in JavaScript. This sample and all the other ones like it are actually in the repo. If you look in, public, assets, JavaScript, code samples, here's all the different assets that I have screenshot or all the different bits of code that I've screenshotted.

[00:06:18]
So if you wanna actually use one and play with it, they're all in here, including this one that I just referenced. Now, this one here, all right, this one actually allows us to calculate the entropy of every image on the page. We can do this with JavaScript. We can grab every single image that has a source.

[00:06:37]
We can figure out how big it is, how many bytes are in it. We can figure out how many pixels are being rendered, and divide them across, that's kind of interesting. We can go in and figure out which images may or may not qualify for entropy. If you don't use this blurring effect or if you don't use backgroundy patterns and stuff like that, this isn't super useful.

[00:06:56]
This is specifically if your website uses this sort of pattern to try and improve LCP. So what is the largest? Well, depending on when things load, a couple of different things could be the largest. So, we look at everything on the page and we calculate its size. So sometimes, if that hero image is particularly slow to load, sometimes that takes 30 seconds to load and it's outside of the LCP window.

[00:07:26]
This thing is the largest thing, which is hero content P, which is 662 pixels by 112 pixels, or 74,000 total pixels. More often, this is the LCP image on our site, which is the desk hero desktop, which is 1740 by 640 or 1.1 million pixels, which is by far the largest thing on the page.

[00:07:50]
So, the LCP in our case is measuring, how long does it take to bring down that giant hero image? And if we replace it with the blur one, it's not actually gonna fix it at all because that'd be too low of entropy. So here's what that looks like if we put it in sequence.

[00:08:06]
So here's that film strip of all the different things that this page looks like during its load sequence, this is in mobile. So when we first load the page, we got a couple of empty pages. We start seeing things draw in. Eventually, this hero image starts to draw.

[00:08:25]
We're waiting for it, we're waiting for it. When that element is complete, the LCP event triggers, which is before the load event, in this case. Now, it doesn't have to be, depending on the website and how you've done things, your load event could be way before LCP, or it could be way after LCP.

[00:08:44]
In the Core Web Vital world, it doesn't matter anymore, really, the LCP triggers when that largest pixel thing were to fire. Now, if we were to add something else to this page, like, let's say we took this big obnoxious banner, and we made it 80% of the viewport.

[00:09:05]
That would become the largest thing, and the LCP would now be that element. So you can decide what you want your LCP to be through design. What do you think the largest thing on your page should be, and how do you make that as fast as possible? Because the design of making something the largest is going to give the indication to the user that this is the important thing, this is why the user's here.

[00:09:32]
So some other considerations, LCP measurement stops after the first user interaction. So that if the user starts doing things, not scrolling, but clicking, mousing over things, typing, whatever, the LCP calculation stops. The user has gotten the indication that the page is done and they can start interacting, and so, if things render after that, it doesn't matter.

[00:10:01]
How fast does this need to be? So according to Google, if for Google to consider LCP good, this needs to be in 2.5 seconds or less. Now, that 2.5 second number is just, that's what they pulled out of their butts, but it's based on data. Think back to why is web performance important, and the research is that anytime after two seconds, a user is going to experience an interruption in their flow.

[00:10:30]
So we're trying to get that less than that. We're trying to get, so that the page feels like it's done in 2.5 seconds or less. Now, what happens if you're not there? What happens if you're more than 2.5 seconds? Well, now we get into penalty zone, and the penalties get worse depending on how bad it gets.

[00:10:49]
What are the penalties? We don't know. These are proprietary secrets of Google, we don't know exactly what the page algorithm is. But we do know that as soon as you fall beyond that 2.5 seconds, there's a direct correlation between your scores and your page rank for those top ten rankings,
>> Todd Gardner: That's LCP.

[00:11:11]
>> Speaker 2: You mentioned LCP monitoring will stop after the user starts interaction. What if the user is clicking their mouse or hovering an empty part of the page before LCP is done?
>> Todd Gardner: Yeah, great question. So, hovering, I think I misspoke, hovering does not trigger as an interaction, right?

[00:11:27]
The user's always hovering on a desktop, they're hovering over something, so it's not about hovering. But if they click, because some users do nervously click, they tap empty bits of background, that does stop LCP. So, there are some limitations to these metrics. So if you have a bunch of users who are all very anxious people and are all constantly clicking on something, your LCP metrics are gonna be off.

[00:11:52]
They're gonna trigger right away whatever has already loaded when the user starts clicking. Now, in a large population sample, generally, that won't be super meaningful, but if you're looking at one particular user's LCP, that can definitely throw those numbers off. Generally, with good design and without super anxious users, the user won't start interacting until they feel the page is done enough for them to start doing things, which is good enough for Google's purpose.

[00:12:24]
If the page, or at least the part of the page that the user sees, looks done enough that the user can start interacting, then LCP doesn't matter anymore. And Google has measured the thing that they were trying to do.
>> Speaker 2: The DOMContentLoaded and LoadEvents, do they apply to single page applications?

[00:12:42]
>> Todd Gardner: Yes, all websites have these events. These events exist regardless of the technology you use. However, when they are fired will greatly depend on what is shipped in the initial HTML that comes out of your server. So, in the example of an entirely client-side rendered application, where that HTML document doesn't really have very much in it at all, DOMContentLoaded and load are probably going to fire very, very fast.

[00:13:13]
They're gonna fire as soon as that initial HTML content is out because there's nothing in it yet, and then your client side rendering application picks up, usually triggered by DOMContentLoaded or load, and starts doing things. And it's this pattern that really made those two metrics kind of worthless in terms of performance measurement, because they didn't mean anything.

[00:13:39]
Now, I'm keeping them in all of these slides for completeness, our example application is partially client-side rendered. There's some stuff that happens on the client, there's some stuff that happens on the server, and so, understanding when these happens can still be useful, in that case, for my own metrics, for my own understanding of a website.

[00:14:00]
But as far as Google's concerned in terms of objectively comparing sites, they don't mean anything at all to Google.