May 12, 2021
The experience of browsing the web can often be frustrating. Remember that when you were reading an article, something suddenly shifted, and you lost where you were? Or you were browsing a store, external widgets or ads loaded, and you suddenly clicked on something you have no interest in? Or worse, erroneously checked out or completed another action that’s hard to back out of without contacting support?
Unexpected layout shifts cause range frustrations and troubles. Fortunately, there’s a metric that helps diagnose them: Cumulative Layout Shift (CLS).
In this post, we explain what CLS is, how to measure and improve it so that you can ensure a positive, frustration-free experience for your audience.
Cumulative Layout Shift measures how much elements move unexpectedly during a page view session, until there’s a five second window of no recorded shifts.
Cumulative Layout Shift refers to the sum of page layout shifts—each time the browser has to repaint an area on the screen unexpectedly, without being prompted by the viewer. It’s a measurement that portrays the overall visual stability of a page and is one of Core Web Vitals—key user experience metrics that are a part of search ranking signals since June 2021.
Cumulative Layout Shift measurements are collected directly by the Chrome browser based on real people’s sessions. You can also gather initial page-load Cumulative Layout Shift in a lab (synthetic) setting. There are differences in reporting based on how you track Cumulative Layout Shift:
|Synthetic (lab) monitoring CLS||Real user monitoring (field) CLS|
|Measured only within the initial page load and cut off accordingly to simulated height of the device or browser. Represented as a single data point for initial load in the specified testing setting.||Measured cumulatively during the entire session lifecycle. Often reported as p75 CLS, which includes varied real user scenarios and network speeds under one measurement.|
Because of these differences, it’s likely the lab-reported Cumulative Layout Shift will be lower than what people experience when browsing your sites and using your applications. Until Cumulative Layout Shift is improved for the lab settings such as Lighthouse (which is happening as the Chrome Speed Team is soliciting feedback), the most reliable strategy is to use synthetic and real user monitoring tools to keep an eye on CLS.
The benefit of pairing lab and field testing is having a clear picture of your audience’s real-world experience and reliable tracking and the ability to reproduce issues in a synthetic setting. Field data is an aggregation of tens of thousands of data points, while lab testing creates a known baseline of a predefined user experience setting (such as a slow mobile device or a fast desktop).
While lab results won’t be the same as Google-reported field Web Vitals, it’s an indicator of your Cumulative Layout Shift baseline. With both types of tools in use, you have a bulletproof tracking system to improve speed metrics.
Each speed metric has a recommended range we can set performance budgets against to make sure user experience doesn’t suffer. Cumulative Layout Shift is measured differently from other metrics (reported in seconds or milliseconds) in a way that it’s a unitless value (a score).
To provide a fast and optimal experience, we should strive for a CLS score below 0.1. A reading above 0.25 is categorised as poor (very likely having a negative effect on your audience).
|Good CLS Measurement||Poor CLS Measurement|
|≤ 0.1||> 0.25|
There are several common reasons why your Cumulative Layout Shift might not be fast:
Images, ads, iframes and any embeds will cause a layout shift if the browser can’t predict their size. Always include width and height attributes for imagery, including responsive images (here’s a fantastic implementation walkthrough).
When dealing with iframes, ads and embeds, investigate the predictable size of the element and statically reserve space for it. The closest the reserved area is to the actual dimensions, the less likely the shift is. Avoiding placing ads and widgets at the top of the viewport is also going to be helpful. Since Cumulative Layout Shift is a stability metric, you aim to create the most predictable loading and viewing experience.
When using webfonts, it’s easy to introduce rendering and shift issues, such as:
To avoid font-related layout shifts, we have to deliver webfonts as critical assets and use the font-display:optional property to avoid layout recalculations. If your fallback font is displayed even momentarily, how visually similar it is to the webfont will also matter. You can test this behaviour with the Font Style Matcher tool by Monica Dinulescu:
When animating elements, it’s essential to minimise layout and repaints. Not all animation techniques are equal. To keep your Cumulative Layout Shift in check, use transform CSS property when working with motion and avoid absolute positioning (top, right, bottom, left) and margin or padding to animate the position of elements. Changes to specific CSS properties will cause layout, paint and composite changes, so familiarise yourself with CSS triggers:
Image carousel animation can be notorious for causing unwanted layout shifts (and present questionable user experience and conversion value), so they are best to be avoided when focusing on Cumulative Layout Shift improvements.
You can visualise and inspect Cumulative Layout Shift on your websites using the Cumulative Layout Shift Debugger:
Performance metrics change. This is especially true for the new generation of measurements, such as Core Web Vitals, that have seen regular updates, bug fixes and recent developments. Cumulative Layout Shift is no different.
Recently, in Chrome versions between 88 and 89, there have been numerous changes to CLS calculation, which might have affected your reporting. You can keep up-to-date with those developments in the Cumulative Layout Shift changelog maintained by the Chrome Speed Team.
Based on the feedback and experimentation on CLS, some of the mechanics behind the metric calculation and its naming will change in tools like Lighthouse soon. While some details aren’t finalised yet, we will likely see a few variants of CLS under different names. These changes address the feedback for Cumulative Layout Shift and aim to make the difference between initial load and page lifetime load CLS more obvious.
Join thousands of subscribers keeping up-to-date with web performance news and advice.
Engineering Manager at Google Chrome