Cumulative Layout Shift (CLS)

[00:00:00]
>> Todd Gardner: All right, let's talk about the second core web vital, Cumulative Layout Shift, or CLS. Now, these are weird words. I mean, all the core web vitals are kind of weird words. When I talk to people who aren't in tech about these things or they hear me mention, this is a really complicated word for what you're actually talking about, and I don't know why they're such big words.

[00:00:22]
But we're gonna break them down so you can really understand them. CLS measures how smooth and predictably elements load into the page. So during that loading sequence, are things moving around? Are things reorganizing? Does the user feel like the page is predictable during that initial startup sequence? Because if the user feels it's predictable, they can start interacting with it sooner.

[00:00:48]
So how does this represent itself in the real world? So here's just a little example that shows off a layout shift. Let's say I'm looking at a page and I'm trying to click to do something awesome. Well, before I click, these irritating ads keep jumping into the page asynchronously.

[00:01:06]
Each one of these is a layout shift. And it's causing that frustration because the user is unsure whether or not the page is done, if more things are gonna happen. Arguably, some sites appear to be doing this almost intentionally, to get you to accidentally click on their ads.

[00:01:26]
We've seen that anti-pattern a lot. Communal of layout shift, the fact that Google is now measuring this, is in some ways addressing that and making it less and less common. Because it is penalizing them in terms of their SEO ranking for that anti pattern. But doing it intentionally isn't the only way it happens, a lot of us do this accidentally and cause this frustration.

[00:01:49]
So if you wanna see how this works firsthand, I built a little game for this that I think is really fun. And it's at shifty.site, and we're gonna play it right now. Feel free, if you're watching online, to jump on and play it or whatever, it's a fun little thing.

[00:02:04]
So, I'm going to go out to shifty.site.
>> Todd Gardner: And I call it, The Layout Shift Challenge. Now, this site basically, intentionally creates tons and tons of layout shifts and gives you the challenge of, can you interact with the site fast enough despite all of the layout shifts? How many of these deal of the days can you click and add to your cart while the layout is rapidly shifting around?

[00:02:37]
My best is eight, let's see if I can go faster here for us live.
>> Todd Gardner: Intense, it's crunch time. Where is it? There it was. I got one. Got another one. No, I don't wanna improve the website. I misclicked. No, I don't wanna join the newsletter.
>> Todd Gardner: Every time one of these widgets load, oop, there's one, it's causing a layout shift, as the rest of the document has to move around it as this new thing pops in.

[00:03:15]
Oop, one second, I got 9. I clicked 11 times, with 82% accuracy. So this is just a little fun thing that I built to show off what layout shifts are, and you can feel free to play this or share it around or whatever. It's just a little fun toy.

[00:03:31]
It's actually open source. It's not on Github, if you wanna see how I built it. Anyway, what this is showing off is, in a very, very extreme case, how frustrating layout shifts can be to the user. Now, this particular game generate a CLS score of 14.58, which is ridiculously huge, and I'm gonna show you next, how do we get to that score, and how do we bother measuring that.

[00:04:00]
All right, so, cumulative layout shift. So here is a little timeline, two frames of the load of our developer stickers online site. In the left frame, it looks like a lot of the page is loaded, and in the right frame, this annoying promo banner comes down to try, I'm trying to ship more of those stickers.

[00:04:20]
So I'm doing like an ad for it at the top of my page, but it pushes everything down. It forces the rest of the document to move. So that's a layout shift happening, but how do we measure that? What is the score of that layout shift? A layout shift is measured by the impact fraction.

[00:04:40]
So, how much of the page was impacted by the move, times the distance fraction, so how much across the page, I'm sorry, not page, across the viewport, did it move? We're only concerned with the viewport, the part of the screen that is visible in the user's frame. That's all that we're measuring.

[00:04:59]
And so, how much of that viewport was impacted by the shift, and how far across the viewport did it move? So let's get into that. All right, so here's that page. In this example, the viewport height is 768 pixels. Now, I'm gonna do an example that only measures height, like, we're just shifting down.

[00:05:22]
But layout shifts happen in both dimensions, like, we can shift down, we can shift right, we can shift in any direction. And so, just to simplify this calculation, everything in this example shifts down, just to make our calculation simpler. So, it looks like we're measuring in desktop view, why are we not measuring in mobile or, what's the difference here?

[00:05:46]
I'll show you a mobile example next, this matters on both, right? Layout just happen on every size device.
>> Speaker 2: And for Google, what do they care about?
>> Todd Gardner: They care about both, okay? So, the core web vitals, all of them, Google captures them for desktop and mobile. And so, they affect both.

[00:06:09]
We're not entirely sure, Google's never actually directly said whether or not desktop ranking is affected by desktop scores and mobile ranking is affected by mobile scores. Google's never explicitly said that. It's kind of inferred, but we don't know that. Now, what I didn't really talk about, but maybe as a good little aside, is that Google does what's called mobile-first indexing.

[00:06:31]
So when Google indexes your website, it's using a mobile version of it. It's only indexing the content that would be visible on mobile. So if you have like a bunch of other stuff that's only visible on desktop screen sizes, it's not even in Google's index, it doesn't care about it.

[00:06:46]
That change went in quite a few years, I think like 2018, 2017. So there might be a use case where Google, you could claim, that Google only cares about the mobile core web vital scores, because they're mobile-first indexing. But they've never said that. They've never said it directly.

[00:07:07]
There's no data to indicate that, so we don't know. What we do know is that Google does capture the data separately for desktop and mobile. And so in a lot of my examples, I'm gonna show you both a desktop version and a mobile version. Sometimes I don't, but the data is applied the same way.

[00:07:24]
Is that your question? Cool, great. So here's an example. This is an example on a small desktop. Here we have a viewport height of 768 pixels. Obviously, the page is a lot longer, but the user's viewport is only 768 pixels high. Now, the impact size of this is the whole thing minus that 60 pixel header on top.

[00:07:52]
So, 708 pixels are the impact size of this shift when that header or when that promo bar comes down. Everything that changes, every pixel that has to potentially change as part of this layout shift is the impact size.
>> Todd Gardner: So, yeah, the impact fraction is we take that impact size divided by the height.

[00:08:20]
So it's 0.922. 92.2% of the viewport was impacted by this layout shift. So, what actually happened? Let's talk about the distance fraction. So again, same viewport, 768 pixels. The distance was really just when that promo banner got rendered in. When that promo banner came in, it was 180 pixels tall.

[00:08:46]
And so, the distance moved is only 180 pixels. So the distance fraction is 180 over 768, or 23%, 0.234, okay? So the layout shift value, what was the score of this layout shift? Is, we multiply those two things together. So, 0.922 times 0.234 is 0.215. It was a 21, it's not really a percent anymore, cuz we kinda multiply them together, Google just calls this the score, or the value, was 0.215.

[00:09:21]
That was the score of this layout shift, how bad it was. Now, this applies on mobile as well, to your question exactly. And in some cases, it's a lot worse on mobile, because we have a smaller screen size to work with. The viewport dimension is smaller generally, on mobile devices than on desktop.

[00:09:41]
And when the viewport is smaller, smaller moves generate bigger scores. So on this case, if we put the whole thing together, the impact fraction here is 0.929, and the distance is 0.308. We multiply it together, and we get an even higher score on mobile than we did on desktop, for the exact same thing.

[00:10:03]
Because the score is dependent on the size of the user's viewport. And so, this is why Google will capture CLS and LCP and IMP, all three of the web vitals on both mobile and desktop, because the scores can change significantly. So as I said at the beginning, this applies to both height and width.

[00:10:24]
Now, I did an example just for simple, describing the problem, that was just about a height shift. But a width shift happens the same way. If you have an image that pops in, say, next to some text, and all that text moves as part of when that image loads, that is also a layout shift that calculates both the height and width of how far things moved.

[00:10:46]
That calculation is just a lot more complicated. I actually went into the blink source code and found where that calculation happens, and it's like 600 lines long and really dense C code. And I didn't feel like that was a good thing to throw on screen and try and describe.

[00:11:02]
But it does apply to both. All right, lastly, there's this annoyingly big mathy word at the start of this thing called cumulative. And that just means, we're measuring the sum of all layout shifts. It's not just one layout shift, there's going to be, 1, 2, 5, 10, 100 layout shifts on your website, depending on how it's built and what's in there.

[00:11:27]
And when we're measuring the cumulative layout shift, we are adding together the score of every single layout shift that happens. Now, there's some things that don't count here. One thing is that, there will be shifts that happen when the user does something, right? Like, oftentimes you'll click on something to expand an accordion display, or you'll click on something and something will appear.

[00:11:53]
These are all like very common patterns, and they don't count. They don't count against your layout shift. If a layout shift happens within 500 milliseconds of a user action, it's not included. Because Google is trying to say, no, elements, part of the page's behavior shouldn't count against you.

[00:12:12]
It's just things that happen without the user doing something. Now, scrolls aren't part of this. A user action is like, click, a type, that sort of thing. Scrolling should not trigger layout shifts. Clicking can trigger layout shifts, and it's okay. So how bad can this be? Well, 0.1, 0.1 is how good you need to be in order to be good.

[00:12:39]
Remember our example here, both of these are enough to be a bad score. Both of these are enough to get an SEO penalty. And our game shifty was like, what, 18, 20, 24 something like that, way more than 1.0. So you have to have very, very low layout shift.

[00:13:04]
You need to basically eliminate this problem in order to get a good score from Google. Fortunately, it is not difficult to eliminate this problem. There are lots and lots of good ways, and we're gonna talk about all of those in our last section around improving web performance, specifically when we talk about improving CLS.