Is your site ready for the Core Web Vitals to be added to page experience search signals? Since the announcement, I’ve come across many resources and tools meant to improve your Core Web Vitals (CWV). Still, very few tools provide detailed information about identifying and improving one of the three Core Web Vitals signals: Visual Stability, also known as Cumulative Layout Shift (CLS). As explained by Google, “a layout shift occurs any time a visible element changes its position from one rendered frame to the next.” CLS measures the combined effect of all unexpected layout shifts on a given page.
A common example used to demonstrate CLS and how to fix it is ads. Since ads are served from third-party sites often, they load after page content blocks and navigational elements, pushing content down or to one side when they finally do display. If your site doesn’t have content blocks for ads, you aren’t off the hook when it comes to CLS, though! Let’s look at how to identify what elements are causing poor CLS and how to fix layout shifts.
Finding Pages With Poor CLS
Identify Layout Shifts
We have several options to find pages with poor CLS, based either on lab data or on real user monitoring, aka field data. It is important to note the difference between these.
Lab data is available from Lighthouse, Page Speed Insights (PSI), and Chrome DevTools. I’ll be using PSI and Chrome DevTools for the examples here. But I prefer running page reports in bulk using the PSI API with our Google Sheets Apps Script or Screaming Frog.
Field data is available from the Chrome User Experience (CrUX) Report. This data fuels the CWV metrics in Google Search Console; the “Field Data” in Page Speed Insights; and a handy Chrome extension, Core SERP Vitals, from defaced.dev. The page in question must have had “a sufficient number of distinct samples that provide a representative, anonymized view of performance of the URL” in the last 28 days to generate this data, per Google. Google’s John Mueller recommends using lab data for more immediate monitoring. Although I’ll use the Core SERP Vitals extension to help find pages that may need CLS help, I’ll need lab data to compare the immediate changes. From the screenshot below, you can see that the two can differ significantly.
Using the Core SERP Vitals Chrome extension (and searching for my favorite hot beverage), I found a few possible candidates for improving layout shifts. The last pictured result shows a 1.0 CLS.
The extension uses field data, but I need to look at the lab data to ensure I can impact it. I’ll run the URL in PSI tool to see what the lab data indicates. to see what the lab data indicates.
Core SERP Vitals uses mobile data, which you can see matches the score of 1 in the PSI report’s field data section. Although the lab data score isn’t as high as the field data, a score above 0.25 is still considered “poor.”
Running the Performance Report in Chrome DevTools
Now that we have a page to assess for layout shifts, let’s open Chrome DevTools.
Load the URL in Chrome. Right-click on the page and select “Inspect.” This will open up the Elements tab of DevTools. We are using mobile data, so we must instruct DevTools to emulate a mobile device. Do so by selecting the icon on the left of the tools menu that pictures a tablet and mobile device.
At the top of the actual webpage, choose the iPhone X to have more shown in the frames. The frames will help us see what is shifting, so the larger viewport will allow us to see more.
Now let’s move over to the Performance tab in DevTools. Make sure you have Screenshots selected.
A Web Vitals option was added to DevTools in Chrome 88, but the layout shift data added in Chrome 84 provides us more detail. You’ll see that the Performance report can look overwhelming with several sections, so I’m not going to use the Web Vitals option. I’d recommend popping the DevTools into its own window by selecting the three stacked dots icon on the right of the DevTools toolbar.
Start a new Performance recording by hitting the reload button or Ctrl + Shift + E (on Windows). This recording will take several seconds to reload and finalize the report. A popup window will appear to indicate what is happening and how long it is taking. Once it is complete, the Performance tab will look very colorful and, as I mentioned before, a little overwhelming.
Understanding the Performance Report Details
We want to focus first on the report’s experience section, which shows layout shifts in red blocks. When you select a specific layout shift block, the Summary tab at the bottom of the Performance window will provide us with details about the shift.
This first layout shift is one we wouldn’t need to worry about. Remember CLS is the sum of scores based on unexpected shifts. This layout shift indicates a user input is what caused the shift. Expected shifts from user inputs are not calculated into CLS.
This second layout shift is unexpected — we can tell since it has a value of “no” for the “had recent input” variable. With this shift contributing only 0.004 to the CLS score, it isn’t too problematic. CLS is the sum total, so if there were several of these, we would need to address them.
This last layout shift block is where we will focus our efforts. We can see it alone contributes 0.23 to CLS, putting it in the “needs improvement” range of 0.1-0.25. Let’s select the Related Node element to be taken to it in the Elements tab of DevTools. Doing this will help us see what was moved.
Now that we know the tagline copy “Embracing the simplicity of natural living and real food” is what shifts, we can check our frames in the Performance tab to see what happened.
Reviewing the screenshots shows that a block of buttons pushes up the tagline during this layout shift.
Fixing Layout Shifts
To fix this, I need to understand what is going on with that block of buttons, so I will inspect them in the Elements tab.
Because “height” is opaque in the Computed styles tab, we know that the height is not actually applied directly to the element; instead, it’s determined by the height of the buttons contained therein.
Rather than relying on the individual button loads to determine the height of this element, I’m going to add a minimum height and see how that impacts the loading and layout shift.
To hard-code this change, I need to pull the full HTML of the website into an editor, make the updates locally, and then have my local files available on a public server for PSI to access it so I can test the effect on CLS. The last part of this is possible thanks to ngrok. If you want to learn how to set ngrok up, Google has a nice tutorial. You’ll need to be familiar with using the command line, so check out my tips on that.
Let’s look at my updated webpage. You can see in the styles that there is now a minimum height of 200px on the div.wprm-recipe-snippets element.
How does this impact our layout shift? The shift on the span.tagline element no longer exists.
And what about the score from our lab data?
We went from a CLS score of 0.255 to 0.031 with one CSS declaration change! Note: the other performance metrics will look wildly different from the original PSI report because this is from a local server.
Think I just got lucky, or that this process only works for certain types of websites? I took this same process and applied it to an e-commerce site.
The lab data on this chai tea category page started off with a CLS of 0.83.
I added a minimum height to the elements with the class of “stamped-product-reviews-badge.”
Again with one CSS declaration, we were able to fix the layout shift. The CLS improved to 0.029 from 0.83!
Although these two examples were fixed by setting a minimum height for elements, another common cause of layout shifts is web fonts, which can change the height or width of content blocks as they’re applied to text within those blocks. An e-commerce client of ours had poor CLS due to web font loading. Some improvements we made that put their CLS in the good range included:
- Changing out icon fonts for SVG
- Updating how fonts display using font-display. Note that if you allow for “invisible text” (FOIT) to display, you will be alerted in the Diagnostics section of PSI. The Diagnostics section doesn’t directly affect the performance score, though.
Even if you don’t have the coding knowledge to fix these layout shifts, take the time to get more familiar with the Performance report. If I can do this for two unfamiliar sites over a couple of days, imagine what you can improve before May! In fact, both of these example sites have already made updates to these elements since I began investigating and writing this post. If they can do it, so can you!
Conclusion
CLS might seem like a small detail, but fixing it can lead to big wins in how users actually experience your site. And while tools and guides help, it often takes a hands-on approach to spot and fix what’s really going wrong. If you’re already investing in an SEO package, make sure it goes beyond surface-level audits and digs into real performance signals like layout shifts.
