Five CLS Questions That Tank Your Shopify Page Speed

You added width and height attributes to every product image. You uninstalled the two apps that looked suspicious. You ran PageSpeed Insights and the LCP number finally stopped embarrassing you. Search Console still flags every product page as failing, and the diagnostic line keeps saying "Avoid large layout shifts." Your Shopify page speed score has hit a wall that image fixes cannot break through. Here are the five CLS questions I get most from merchants who have already done the obvious work, and the answers that actually move the number.

Why does my CLS score look fine on my phone but show up red in Search Console?

CLS does not surface the way LCP does. LCP shows up as "my store feels slow" the moment you open the page. CLS happens in the first second or two of load, on a first visit, on a mid-tier device. By the time you check on your iPhone with a warm cache and your home Wi-Fi, the shift has already happened off-screen and you missed it.

The 10,205-store dataset that floats around r/shopify pegged the average Shopify CLS at 0.12 on desktop and 0.09 on mobile, both either over or hugging Google's 0.1 "Good" threshold. Search Console reports field data from real users, who arrive on cold loads, on mid-tier phones, often on patchy mobile networks. That is the version of your store that tanks your Shopify page speed scores in the wild.

The diagnostic that actually catches CLS is in Chrome DevTools, not PageSpeed Insights. Open your store in an incognito window. Open DevTools. Go to the Rendering tab (you may need to enable it from the More Tools menu first). Check "Layout Shift Regions." Reload the page. Anything that shifts will flash blue. PageSpeed Insights tells you something is shifting; DevTools shows you what.

Fixing the announcement bar that keeps jumping on Dawn

There is a one-line bug in Dawn's snippets/cart-drawer.liquid that has been live since at least 2024. The cart drawer is rendered with visibility: hidden, which hides it visually but still occupies vertical space in the layout. As your sections progressively render, the drawer briefly takes a computed height, and the announcement bar above it shifts down and then back up. Browsers count both moves as layout shift.

The fix is one CSS property. Take a theme backup first, the way you should before any code edit. Then:

1. Go to Online Store > Themes > Actions > Edit Code.
2. Open snippets/cart-drawer.liquid.
3. Find .drawer { visibility: hidden; } and change it to .drawer { visibility: hidden; position: fixed; }.
4. Save and rerun PageSpeed Insights on a product page after about an hour (the field data takes time to refresh).

With position: fixed, the hidden drawer is yanked out of the layout flow entirely, so its visibility state no longer pushes anything around. This was first documented by a user named nicolasdm in a Shopify Community thread. I have seen it work on Dawn out of the box. I have not tested it on every Dawn fork or on premium themes that copy Dawn's drawer pattern; if you are on Prestige or Impulse or a heavily-forked Dawn, find the equivalent off-screen panel that is still in the layout flow and apply the same idea.

I added width and height to every image. Why is my CLS still failing?

Because images are usually not the cause.

I used to default to "set explicit dimensions on everything" as the first CLS fix. After running the DevTools overlay on enough stores, I changed my mind. On most Dawn-based stores, image dimensions are already set in Liquid; the shifts you see in real testing come from something else. A review widget. A delivery-estimate banner. A currency switcher. A cookie consent prompt. A chat bubble that loads after first paint and pushes everything below it down.

One Shopify Community thread had a merchant who set image dimensions in code, ran the test again, and got the same 0.5 CLS score. The shifting element turned out to be a rich-text__wrapper block whose height was determined by content that arrived a beat after first paint. No image involved.

The practical move: stop trying to fix CLS by guessing. Open Layout Shift Regions in DevTools and watch what flashes. If your image carousel flashes, fix dimensions. If your reviews block flashes, dimensions on images cannot help you, and you need the next answer.

Which review and delivery widgets are the worst, and how do I stop them shifting the page?

Anything that injects content after first paint can shift the page. The usual suspects: Shopify's own Reviews App, Judge.me, Loox, Yotpo, Stamped, Shop Promise delivery estimates, currency switchers, cookie banners. They are not all equal, but they share one property: their final rendered height depends on dynamic data, so the theme cannot reserve space for them at build time.

The fix is to reserve space yourself. Wrap each widget in a CSS container with a min-height set to the rough rendered height. For a star-rating block on a product page, that might be 24 to 32 pixels. For a review summary section, 80 to 120. For a delivery-estimate line, 24. The widget then loads inside that reserved space and the elements below it do not move.

The cosmetic objection from merchants is fair: a blank rectangle before the widget appears looks broken. The cleanest answer is a skeleton loader styled to look intentional, like a light grey placeholder bar or a faint outlined block. If you do not have time to build that, an honest blank space is still better for your Shopify page speed score than a 200ms downward shove of every section below the widget.

If you have multiple post-paint widgets stacking on the same page, fix them in the order their containers appear from top to bottom. The deeper down the page a widget sits, the more elements its shift drags with it.

Desktop CLS is often worse than mobile, even though everyone tells you to optimize for mobile

This is the strangest finding from the 10K-store dataset and almost no one has written about it: average desktop CLS (0.12) is worse than average mobile CLS (0.09). Both are at or over Google's 0.1 threshold. Yet most Shopify CLS guidance, including Google's own PageSpeed Insights framing, treats mobile as the primary target.

A reasonable guess at why: themes are designed mobile-first now. Mobile gets the careful breakpoints, the reserved space, the lightweight components. Desktop inherits the leftovers. Two-column layouts that stack to one column at the breakpoint reflow when the breakpoint flips. Hover states render conditionally. Sticky headers behave differently. Desktop has more horizontal real estate for elements to slide into when an image arrives late or a script paints a banner.

I do not know whether Google weights desktop CLS the same as mobile CLS for ranking purposes. The official line is that Core Web Vitals are evaluated separately by form factor; in practice, Search Console shows desktop CLS failures alongside mobile failures and treats both as "issues." If your desktop CLS is failing while your mobile is passing, your Shopify page speed score in Search Console will not let you ignore the desktop column. Test both.

The DevTools workflow that beats PageSpeed Insights for CLS

When the obvious fixes have not moved the number, this is the workflow I use. It takes about ten minutes per template.

1. Open your store in a Chrome incognito window with cache disabled (DevTools > Network > "Disable cache").
2. Open DevTools, go to the Rendering tab, and enable "Layout Shift Regions" and "Paint Flashing." Reload. The shifting elements will flash blue. Hover over each flash and use Inspect Element to find its class or ID. Write the names down.
3. For each flagged element, ask: is its size known at first paint, or is it filled by JavaScript after the page loads? If the size is unknown, that is the offender. Reserve space.

If you want a faster path that works without the DevTools dive, PageSpeed Insights' "Diagnostics" section has an "Avoid large layout shifts" entry that lists individual shift sources by selector. The selectors are not always clean (#shopify-section-template--16-product is not a label that helps), but Inspect Element will resolve them.

If you have hit step three, applied the fixes, and your CLS is still over 0.1, you are within striking distance of where a help1 expert can look at your store in real time and point at the specific Liquid block that is still moving. Most CLS work is a one-off audit, not architecture; an extra pair of eyes for fifteen minutes usually closes the gap. The same diagnostic flow applies to other Core Web Vitals failures; our hero image LCP guide covers a different trap on the LCP side.

I will say this and merchants will keep ignoring it: stop optimizing your Shopify page speed score by chasing image weight. Image weight is a finishing fix. The bigger wins come from not letting things move. Reserve space, freeze your dynamic content into known dimensions, and your CLS number will drop further in an afternoon than another three weeks of image compression ever did.