 Hello, and welcome to the CSS Podcast. This season, we're answering your most burning CSS questions. And today, we're covering a very common CSS issue. Why do I have Layout Shift here? One of the key core of vitals, which measures UX performance, is CLS or Accumulative Layout Shift. And it measures the instability of a page's content, scoring experiences low if the content is unstable, shifting around, and jumping and moving while you're trying to read or interact with it. So CLS measures how much visible content shifted in the viewport, and by how far those things moved. Awesome recap. The worst offender of this being that moment when you were just about to click a button, but then the layout shifts, and the button that was under your mouse is no longer under your mouse. It's like the worst case as a new button that's put there. And you just click the wrong thing. You're like, I didn't want to click that when my mouse was clearly where. Anyway, it's really, really frustrating. It's also annoying when you're trying to read something, and then it goes away. That's the annoying one. Totally. You're reading that headline. You're like, how to do a hero image loads? And you're just like, where was I in this paragraph? I was somewhere. Yeah, the ad loads in. And now I'm gone. Jeez. So in today's episode, we're debugging it and labeling various things that can cause cumulative layout shift. So here's a high level of those main offenders. There's images, iframes, or ads that don't have dimensions. There's ads, embeds, and late loaded third party components, or content. There's animations, and also fonts can be contributing to CLS. Yeah. And with those items in mind, I'll start with a high level. It's worth distinguishing the types of layout shifts. There's load layout shift, which you even mentioned them here. You were like, there's late loaded content, and there's stuff without dimensions. Anyway, they have a name. There's load layout shift and post load layout shift. And you can expect, oh, there's also expected layout shift where the user invoked it. Like, I did a thing. I changed the tab. Of course, the layout should shift. And I should not be like that one I'm expecting. So anyway, those are the three main ones. And each of these types are played out in various ways, which we're going to go over. So load layout shift happens while at load time. But specifically, it's up to five seconds after the page loads. So when CLS is being measured, it looks at what's happening for those first five seconds. And that's called the load layout shift phase, I guess. Anyway, there's a post layout shift that's the phase that happens after that. So that's anything after five seconds. And expected layout shifts, like the ones we talked about, where the layout shift could even be desired, right? Changing a tab. I scrolled something. I selected a new element that changed the whole thing. Anyway, that's the three different high level types of CLS that we have. Lots of different types of layout shift. So I'm glad that you pointed that out, especially when it's expected. That's a little different. So we mentioned the main offenders. Let's break those down a little bit more. So the first was the image load layout shift. And that's mostly from images without any sizing attributes. We talked a little bit about images and how to make sure that they're not distorted and how to make sure that they're optimizing them. The last episode, so check that out, too. But the browser will discover the image size later and apply it as soon as it's known, which is probably just in time to interrupt your reading. My favorite part of layout shift. But this is mitigated by specifying the sizes of your images on the image tag itself with width and height. And it's important to point out that these sizes aren't direct. They're soft, so they can still be adjusted. And they're primarily used for telling the browser the aspect ratio of the image. So you can also use aspect ratio for this by setting an aspect ratio style on the image. And this can be used to allocate layout space for the image before it actually has any pixel data to show or learn from within that media. So just the container to have knows the size that it needs to save for that image to load. So putting sizes on your images is really good for lazy loaded images, whether that's from JavaScript or HTML, as the sizes will place hold that space for the image while it's being lazy loaded or using the aspect ratio of poverty to do the same thing. Awesome. Another main offender is JavaScript loading, which it's lazy, right? So we've got ads, images, or iframes. iFriends, we've got images or iframes. We should call iframes iframes from now on. Iframes. All those are not usually friendly. But yeah, these same things, just like images, it's made worse if they don't have sizes on them, right? You can put sizes on an iframe, you can put sizes on your images, sizes on your widgets, especially if they're lazy loaded, this can allow that pre-allocated space or your place holding. And if you don't know the size of the ad or whatever it is, which is probably unlikely because ads are purchased by size, but let's say it's an iframe, you don't know what size it should be, you should still place hold something because having something is better than nothing. You can incur less CLS bad scoring, like it less penalties if the image has only shifted a few pixels versus it's shifting a whole bunch of pixels. So some is still better than nothing here, even if it's really dynamically lazy loaded. Yeah, that makes sense. So also speaking of lazy loading, lazy loading CSS or fonts or even grid definitions can manifest in a couple of ways. So if we talk about fonts like lazy loading, fonts can adjust how your page looks from every single line of text. So a different font can result in different line wrapping, which means that post load of a new font can not only visually swap characters, but it can also change line lengths and line heights and overall page content. And it could even be as bad as a large headline wrapping onto a new line, because it might have been wider font with this new font, which can cause a pretty large jump in page height. On my website, I have like 120 pixel fonts for headings. I have really big headings. Another issue could be font weights, where a bolder font will consume more space and maybe cause new lines to wrap as well. And finally, lazy grids are where the grid CSS is loaded late and causes a visual jump when it's loaded and has created the rows and columns. And this was also particularly bad because that can cause a whole slew of different types of elements to shift and cause cumulative layout shift. Nice. Yeah, CSS we don't always think of being a main offender, but it can be an offender in a lot of ways. Like another way is we've got grid layouts getting its sizing from children. So maybe just even the grid definition was late and that caused CLS. Maybe it's a grid that only knows its size because it's looking at its children and its children were lazy and well, I just caused this rippling effect of CLS. And so while grid may be the cause of CLS, it can also get you out of CLS. Grid is very good at defining row sizes, which can be given a size before the content has appeared or even a minimum size so that when that lazy content does load, it's again less of a shift and less shift will reduce the penalty that you'll incur for them. Yes, that is definitely one to think about as well. And finally, interactions can cause changes in sizes too and that's a user-initiated layout shift. So for example, that might be on focus or on hover. You might move over an element which also moves other elements unexpectedly and therefore it shifts the entire layout or you scroll to the end of the experience and more content is loaded via an infinite scrolling experience and this can also cause layout shift in your UI. So just other things to think about when you're interacting with the site. Nice. Oh, well that just leaves us with kind of tools and tips. So we've gone over the main offenders. These are really good things to be thinking about. And then here's a few of our tips for kind of combating CLS. And one of the first things that we want to mention, especially because we know the Chrome team is gonna come on us to mention this as well, that there's a difference between lab testing and field testing with CLS, right? CLS is all about like later loading of things, late discovery or all sorts of these things that have to do with timing. And timing is gonna be due to your network. And if you have a slow network, the timing could be very different. So if you have a fast network, maybe it was able to not have a lot of CLS, fetch things quickly, if it's slow, it could go slow. So anyway, there's a difference between lab tools and field tools. So whether you're testing on an actual device or you're just testing simulations and they want you to know that, I'm sure it's no surprise, but those things can be different. So the Chrome UX report or Lighthouse or just simple page loads, they might not reflect the reality when using these online tools because they're on the cloud and they have a lot of resources. So test as much as you can in the field on actual devices. You can also test with a tool called Lighthouse. So Lighthouse will show you which elements with screenshots are offending elements for CLS. So it's worth running this on your page and inspecting the tips and tricks that it has for you. It actually gives you some advice for how to reduce CLS and other core vitals metrics how to improve those. So you can access Lighthouse in Chrome DevTools. There's a few different ways that you could add an extension to. Also as a side note, Lighthouse will often show you which elements were shifted, not necessarily what causes that shift. So if JavaScript inserts an ad into the sidebar, the report will show all the children underneath it as shifted, but it won't necessarily be able to say that the ad was the cause of that shift. So you might have to go and inspect yourself and see why things are happening. You might also want to open the network panel and see how things are loading in. That might help. Or even snapshots of the page load, which are in Lighthouse too. Oh, good call to the snapshots. That's a great way to debug because you can go back in time, right? You'd be like, what happened right before my shift? Awesome. And the last tip here for inspecting and testing is the performance panel in DevTools. It can highlight layout shifters. You might even see the little badges in there that say CLS. You can find them also in the experience section. This will highlight and read on the actual page too, the areas of shift. So that's kind of nice. You get an in-page overlay and it will also show them in the timings area of the audit. So that's where you'll see those badges. It'll tell you CLS and other things that are going bad mostly in there. But yeah, use the performance panel. Nice, love that. So that's all we have for our show on layout shifts. If you have any questions, we'd love to answer them on the show. Just tweet us with the hashtag CSIS Podcast. You can find me on the X at Yuna, that's UNA. On the X. We're gonna have to get used to this verbiage. And I'm on the X site also as Argyle Inc, ARG, Wiley, INK. And your question could hold a lot of people. Shoot it to us. Shoot to us. Also, if you like the show, please share this with a friend, a coworker, someone that you mentor, people that you went to school with or boot camp with, because those reviews help other people discover our show, you sharing it with other people, help them discover our show even faster. And that helps us have more time to create content for you. Awesome, looking forward to your questions, y'all. Thank you.