Layout shifts aren't a good look and should be below 10%. And while it might actually attract visitors in some contexts, shifts on a website might lead to page abandonment. But there's more to it.
While weight of the Cumulative Layout Shift metric as part of lab data is only 5%, it actually makes up 33% of Google's Core Web Vitals.
Why Cumulative Layout Shift is a big deal
So, next to pagespeed in general, enough reason to address layout stability issues and reduce user frustration. And that's exactly why it got introduced. For example:
- you wanted to click on a link, but a layout shift lured you into clicking another link (Google is actually doing the same when returning to the SERP's 🙈);
- you were reading an article, and an ad sliding in forced you to scroll back to the reading position you were left behind.
As Google is explaning as well, it is often caused by client side rendering. However, changing CSS on the fly while scrolling (often initiated by JavaScript as well) and images could cause layout shifts as well. Especially when images are lazyloaded. That's why PageSpeed Insights is now recommending to explicitly set image width and height attributes for an improved pagespeed score.
Lab data versus field data CLS
So, those are the main causes and CLS caused by images is quite easy to detect, even in laba data. However, as lab data is based on synthetic testing, it won't:
- scroll all the way down;
- interact with your page, such as adding products to your cart.
Within my pagespeed projects, that's often where challenges start though: field data, or just real user behaviour and interaction. As we started doing more using client side rendering or JavaScript in general, more unexpected outcomes could occur. Such as layout shifts next to SEO crawlability challenges.
Field data CLS characteristics
Although layout shifts due to user interaction wouldn't become part of Cumulative Layout Shift (for example, when showing the answer within an FAQ), all shifts during the full page life cycle were tracked. That's why it's called Cumulative Layout Shift, with emphasis on cumulative. So, your Pinterest widget just on top of your footer, inserting images on the fly, would cause a layout shift.
On page navigation, the CLS would be reset to zero. However, this only happened on hard page navigation.
CLS shortcomings
You wonder why this nuance of hard page navigation is important? Well, SPA's and most PWA impementations don't have hard page navigations. As data of the new page would be fetched using API/REST calls, new contents would be replaced or inserted, instead of going to a new page. Sure, the url in the addressbar would change by just using some JavaScript. But this actually is a soft navigation instead of a hard navigation.
And that's where SPA's and PWA's got punished quite a lot, as layout shifts would be added infinitely for all URL's, from the start of a new session (or page refresh, for example. You might now be able to imagine how this could result in quite a red CLS score.
Meet the new CLS: session window
So, a change was needed, and so they (Google) did. They were actually already testing this out in the field to see if their new CLS approach would be a fair take instead. And here it is:
Currently, Cumulative Layout Shift score would reset itself after a hard page navigation. Within this new setup, session windows are introduced. How this works:
- layout shifts are tracked (if it not happened within 500ms at user interaction)
entry.hadRecentInput - as soon as there is a gap of one second since the last layout shift, a new layout shift counter will start as of the new layout shift while remembering the previous sum of layout shifts;
entry.startTime - prevTs > 1000 - if layout shifts are happening over a period of 5 seconds, only the layout shifts within the first 5 seconds will end up as a cumulative layout shift score and a new counter will start.
entry.startTime - firstTs > 5000 - The score of a session window with the higher cumulative layout shift will then be reported to Chrome User Experience Report:
max = Math.max(max, curr);
Is Session Window CLS a good change?
This Cumulative Layout Shift change might actually be a good change in multiple ways:
- If an earlier first layout shift maybe exceeding 10% didn't scare off visitors yet, then there is less reason to cumulate all layout shifts;
- And as SPA's and most PWA's aren't doing hard navigation, they won't be 'punished' as much via this CSL update.
Side notes of CLS change
Wondering if there are any downsides? As CLS already was depending on user interaction during full time on page, CLS could and often would vary a lot. This won't change. Moreover, it will even be harder to get a sense of what the real UX CLS of all window sessions could look like, making it a bit harder to debug if you're only working with field data.
55% of origins will not see a change in CLS at all at the 75th percentile
web.dev
While 55% of origins won't see a change, only 3% of origins will actually move from poor/moderate to good bucket. That isn't a lot. So, while individual CLS score might improve a bit, don't expect to suddenly pass Core Web Vitals.
Launch of Session Window CLS
It is not clear yet in which Chrome version we will be seeing this update. This makes it also quite unsure if it will already be part of Core Web Vitals as a Google ranking factor.
However, you can already start testing this new CLS yourself to know what you're up to or how CLS might change. Curious to know where your issues are?
