When elements load it is registering a layout shift, but the only shift is those elements appearing

Question

I have been trying to tackle CLS on this website for a while and recently I discovered the performance tab and found, to my dismay, that the layout shift that is being registered is simply elements loading. The elements are not moving, shifting, or pushing anything (that I can see), it simply sees a new element has appeared and calls that appearance a layout shift.

Has anybody ever seen anything like this? Could it be that the whole site loads so slowly that the appearance of a new element is seen as a shift from the baseline?

Here's the webpage in question: https://www.wallbedsbywilding.com/murphy-beds/

I also attached a screenshot of the "Layout Shift" panel in the performance tab of dev tools. As you can see, the elements "shifting" are "moving" from [0, 0] on the page to an actual location. I interpret this as basically saying that they appeared, and that is being considered a shift.

I have tried disabling lazy loading on images and using as much inline css as I can. I thought maybe the CSS was lagging, but it didn't change it one little bit. I have also tried adding explicit width and height on images, still no dice.

Answer 1

Based on desktop data for the given url (as well as its homepage and origin data), the CLS is happening/picked up by Core Web Vitals for sure: https://www.rumvision.com/tools/core-web-vitals-history/www.wallbedsbywilding.com/path/desktop/?path=/murphy-beds/

When checking for CLS during my own page visit, I can confirm it's there:

// log all CLS events to your console 
// when a CLS is unexpected (hadRecentInput=false), an additional console.warn will be triggered
// but if the sum is exceeding 0.1 (the minimum CLS threshold), an error is logged to the console 
// more nuances and how CLS is being measured per 5 second window sessions:
// https://www.erwinhofman.com/blog/google-announces-cls-metric-will-change-how/#meet-the-new
let cls = 0;
new PerformanceObserver(l => {
    l.getEntries().forEach(e => {
        console.log(e);
        if (!e.hadRecentInput) {
          cls += e.value;
            if ( cls > 0.1 ) {
              console.error('Current CLS value:', cls);
            }
            else {
                console.warn('Current CLS value:', cls);
            }
        }
    })
}).observe({type: 'layout-shift', buffered:true});

What I actually often do is turn of JavaScript, and spot the differences. And that's often working.

On your shared URL, I then see a #request-follow that sits in between .ekr-header-container and the hero group. With JS enabled, the uikit.min.css will set it to display:none using the .uk-modal selector.

However, the .uk-modal class is added later in time via a deferred uikit.min.js. That is causing the biggest CLS and fixing that should come with a big improvement already.