The CLS Cheatsheet (Vol. 4)

Prologue

This is the fourth and final instalment of our series. In this piece, we’ll dive into our experiences and insights gained while tackling this project at Housing.com.

Previous Chapter:

CLS: Changing the perspective (Vol.3)

Over the years we have tried a lot of approaches, some approaches required design inputs while on the other hand some ideas were tech driven. We eventually found out that there is no one solution that fits all. We believe if the fundamentals of layout shifts are strong, there will be multiple solutions to each use case. Below is the compiled list of use cases we encountered over the years and our take at what could be the best solution to it

Over the years, we’ve experimented with numerous strategies, some needing design expertise and others driven by technology. We learned that there isn’t a one-size-fits-all solution and were convinced that with a solid understanding of layout shifts, there are many ways to tackle each scenario. Below is the curated list of use cases we encountered over the years and our take at what could be the best solution to it

Standard CLS

standard cls

When we talk about CLS, this is the most standard use case that majority of the people convey and so are we!
If any content loads after a section has already appeared, it’s best practice to include a placeholder, so that the section below it doesn’t move. For instance, in the example mentioned above, the image on the right could cause a CLS if it lacks data.

Container Height CLS

sync loading cls

According to Google,

Layout shifts that occur within 500 milliseconds of user input will have the hadRecentInput flag set, so you can exclude them from calculations.

How does this statement apply to this case?
If a layout shift is expected following a user’s click, we should eliminate any asynchronous activity in those operations. Taking the FAQs example into account, the second question should either preload the information or reserve a specific height to accommodate any asynchronous content that might be added later.

Text Overflow CLS

text overflow cls

Sometimes, developers may not know the precise height of a container because the amount of text displayed can vary greatly. In these instances, if the text is static, it’s crucial to keep it within the layout’s acceptable height limits. For dynamic text, using ellipses is a practical solution to ensure the container’s height remains consistent.

Vertical CLS

vertical cls

This scenario is likely the most frequent yet commonly neglected one. When the number of elements in a list is uncertain ( often in cases where the list is populated from an API ) it’s recommended to opt for a horizontal layout to prevent any layout shifts. Vertical layouts should only be considered when the number of items in the list is known/predetermined.

CLS Mitigation Strategies

• In situations where multiple components load at the same time, it is preferred to control the rendering sequence. This means ensuring that one component fully renders before the next begins. This approach keeps all components loading smoothly and sequentially, avoiding any layout shifts.
• If client-side navigations are not managed with proper loaders, they could negatively impact the CLS score. For example, when navigating from page A to page B, the transition might extend beyond the ideal 500ms window for CLS due to time-consuming processes like API calls and layout computations.
• In cases where layout shifts are inevitable in certain sections, it’s best to position these lower down on the page. The fewer people interact with these shifts, the better the CLS score will be.
• When time is limited, it might be acceptable to overlook layout shifts on non-indexed pages since they are not considered in Google’s user experience report. However, if a non-indexed page is connected to an indexed page through client-side navigation, it’s important to address these layout shifts, as the CLS score from the non-indexed page can affect the indexed page!

Quick Tips for CLS report

This report is divided into two sections: Real World Data and Lab Report.

• Real World Data: The CLS score in this section is derived from the Chrome User Experience Report, providing a reliable gauge of whether actual users are experiencing layout shifts.
• Lab Report: This section presents report from a test conducted specifically for your analysis. The scores here reflect only this test and cover only the initial viewport (first fold). Therefore, the CLS score in the lab report corresponds solely to the layout shifts that occur within this area.

Real world data is collected only for indexed pages. Layout shifts on non-indexed pages are not included in this data. If you’ve addressed a layout shift on a page but it still appears in your Google Search Console, and the issue persists even after executing “VALIDATE FIX,” it’s likely that there hasn’t been sufficient user interaction with the updated version of the page for the CRUX report to reflect the change. This lack of new data means the Google Search Console report may not show an updated status.

CLS Memory Map

memory map

I have created a flowchart that outlines the daily thought process used to assess whether a particular requirement might lead to Cumulative Layout Shift (CLS). Here’s a short description of the flowchart:

• Is it a first fold feature? Layout shifts here can be readily detected in the lab report.
• Is there an API call involved? If so, confirm that designs are in place for all stages of the data fetching lifecycle.
• Check for any front-end optimizations that might induce layout shifts. In our situation, we use Loadable, which requires managing a placeholder state.
• Validate the designs to ensure that layout shifts are accounted for, such as in scenarios where data overflows or is absent.

This marks the end of the CLS series. Hope we helped in demystifying layout shifts at scale!