Layout Shift Is Why Customers Tap the Wrong Thing

Cumulative Layout Shift adds up every unexpected movement of visible content on a page, weighted by how much of the viewport moved and how far. Google calls anything under 0.1 good and anything over 0.25 poor, and it's one of the three field metrics, alongside Largest Contentful Paint and Interaction to Next Paint, that make up Core Web Vitals in Search Console. The word "unexpected" is the important one. A shift the browser already knew was coming, like an image that had its width and height reserved in advance, doesn't count against you. A shift it didn't see coming does.

"A shift the browser already knew was coming, like an image that had its width and height reserved in advance, doesn't count against you. A shift it didn't see coming does."

What CLS is actually counting

The usual causes are boringly consistent across stores. Images and embedded videos without width and height attributes, so the browser can't reserve space before the file loads. Web fonts that render at a different size or spacing than the fallback font, so text reflows once the real font arrives. And dynamically injected content, cookie banners, review-star widgets, upsell bars, chat launchers, all landing after the layout around them has already settled, and all pushing it down or sideways when they do.

Finding the actual culprit on your store

Chrome DevTools' Performance panel has an Experience section that flags individual layout shift events and shows you which element moved, when, and by how much. That's more useful than a single CLS number, because the score tells you something's wrong without saying what. Open a product page in an Incognito window on a throttled connection, so the shifts play out slowly enough to watch, and look for the usual suspects: does a reviews widget pop in two seconds after everything else and shove the buy box down? Does a size-guide banner or shipping-estimate bar appear above the price after the page looks finished? Is there a cookie consent bar sliding in from the bottom that shifts the whole viewport?

Once you've found it, the fix is almost always the same move: reserve the space before the content arrives, not after. A fixed-height container for the reviews widget even while it's loading. Explicit width and height on every image tag. font-display: swap paired with a fallback font sized to match the metrics of the real one, so the reflow when it swaps is small enough not to register. None of this is a redesign, it's holding a space open for something you already know is coming.

"It's worth checking scroll-triggered shifts separately, because they don't always show up in a straight page-load test."

It's worth checking scroll-triggered shifts separately, because they don't always show up in a straight page-load test. Lazy-loaded product recommendations, a "you might also like" carousel, or infinite-scroll collection pages can all push content around after a customer starts scrolling rather than on load, and Google counts those the same way it counts a shift on first paint. Scroll a product or collection page slowly, in the same throttled Incognito session, and watch for anything below the fold reflowing as it comes into view. A carousel that hasn't reserved its own height before its images load is one of the more common culprits here, and one of the easier ones to miss if you only ever test above the fold.

Why this now matters twice over

The thumb-slip problem is the one people can picture immediately. The newer one is less obvious: AI browsing agents run into the same failure for the same reason. An agent working through a checkout locates an element, whether by its position on the page or through the accessibility tree, and acts on it a moment later. If the layout has shifted in that gap, the agent's click lands on whatever's now sitting in that spot, exactly like a human thumb hitting the wrong target. It's one of the concrete ways a page can have everything an agent needs to complete a purchase and still fail the interaction, a point covered in more detail in Can an AI agent actually buy from your store?. A page that's stable enough for a distracted human on a train is, it turns out, also the page that's stable enough for the software increasingly shopping alongside them.

CLS is one of the few Core Web Vitals you can demonstrate to someone in ten seconds without any tooling at all. Load a product page on your own phone, and the moment it looks ready, tap where the Add to Cart button is. If you land somewhere else, that's the metric, not an abstraction. Go back into DevTools, find the element responsible, and give it a reserved space before it loads instead of after. It's a small, unglamorous fix, and it's one of the few on this list a developer can usually knock over in an afternoon.

At beCommerce, we track down layout shift culprits as part of every technical and mobile UX review. If you want a hand finding yours, book your free audit →.