A Stack Overflow user posted a question asking for help debugging CLS issues on https://shop.alterair.ua/.
According to PSI, the origin-level CLS in the field is rated “needs improvement” for both desktop and mobile experiences.
CLS is the only thing holding this site back from passing the CWV assessment, although the site does also have mobile INP issues, which will be a blocker soon.
Despite the CLS issues in the field, CLS in the lab is very good. It’s actually the only metric that isn’t performing poorly. On desktop it’s 0.003 and on mobile it’s 0.000.
This web perf challenge is to try to figure out where the layout shifts are coming from to be causing the origin to be failing the CLS assessment. If you find any sources of layout shifts, please also share your workflow (screenshots or videos would be super helpful) so we can all learn how it’s done.
It’s most likely the product page
- product pages are normally the most visited page types on retail sites
- loading CLS is anywhere between 0.115 and 0.052
- scrolling CLS is anywhere between 8.x (yes that’s really 8) to 0.57 ish
Some of the LayoutShifts seem genuine but then there’s entries like this one that suggest there’s a Chrome issue at play:
{
"previousRect": {
"x": 0,
"y": 0,
"width": 750,
"height": 1334,
"top": 0,
"right": 750,
"bottom": 1334,
"left": 0
},
"currentRect": {
"x": 0,
"y": 0,
"width": 750,
"height": 1334,
"top": 0,
"right": 750,
"bottom": 1334,
"left": 0
}
}
For the scrolling CLS, some that are considered to have moved aren’t even visible to the visitor
There are some small visible Layout Shifts on load and some larger ones on scroll
But I’m also seeing a bunch non-visible layout Layout Shifts that are being measured for CLS mainly around the FAQs
Tools wise used DevTools and https://chromewebstore.google.com/detail/core-web-vitals-visualize/mcffmgagphgpgkdclllnilokablhjcge using mobile emulation
In such a scenario, my initial step would be to load the page using treo.sh. This will display the pages that receive sufficient traffic to be included in the CrUX dataset.
This will show that errors accure on the PLP page (/otoplenie/teplovye-nasosy/)
Next, I would load the page to check if I can detect any Cumulative Layout Shifts (CLS) during the initial loading. If it’s not immediately visible, I’d open the developer tools, navigate to the performance tab, and throttle the network connection to capture a performance trace. This trace would provide a filmstrip view of the page’s loading process. Hovering over these images can offer a visual representation of any layout shifts. Simultaneously, I’d keep the console open, where the Web Vitals plugins would log all the core web vital metrics and their scores. In most cases, I also disable JavaScript (Open devtools setting > disable javascript) to observe any disparities between the initial HTML and the final state after all JavaScript has been processed. If I can’t identify any issues during the initial loading phase, I proceed by scrolling through the page and interacting with its elements, such as opening filters, dropdowns, menus, and more.
In this particular scenario, I’ve already identified an issue with Cumulative Layout Shift (CLS). As I scroll down the page, the filters become position fixed, leading to the removal of the initially reserved space for this element. This, in turn, results in a shift in the catalog body, causing a layout shift.
hope this helps
1 Like
For desktop, I would follow the same steps as mentioned earlier. Here, you can observe a distinction between the initial HTML (without JavaScript) and the final state. During the loading process, we notice certain products being inserted above the banner, leading to a downward shift of both the banner and all the products.
These result in a layout shift that is reported by the Core Web Vitals plugin in the console.
1 Like
Someone should probably reply to them on StackOverflow 
Good suggestion, I added a comment with a link back to this thread
