Cumulative Layout Shift is the Core Web Vital that punishes you for content jumping around after the page starts rendering. Hyvä’s lightweight Alpine.js-driven approach should keep CLS naturally low, and on a clean default theme it does. The places CLS goes wrong on Hyvä-themed Adobe Commerce stores are predictable: third-party widgets, conditional content blocks, image dimensions, and a handful of Adobe Commerce-specific patterns that introduce shift in ways most general performance guides do not cover.
This piece walks through the specific shift sources Bemeir’s Hyvä team consistently sees and the fixes that hold CLS under 0.1 on real production stores. The Adobe Commerce-specific issues are the ones merchants miss most often because the general web performance advice does not address them.
The threshold and what it means
Google’s “good” threshold for CLS is 0.1 at the 75th percentile. “Needs improvement” is 0.1 to 0.25. “Poor” is above 0.25. The 0.1 number is small; it is the equivalent of one significant shift on most pages or several minor shifts. The merchants who are still in “needs improvement” range usually have one specific shift source that is doing most of the damage, and identifying it is the first step.
The Chrome DevTools Performance panel marks layout shifts in red. The recording from a page load gives you exactly when each shift happens and which element was responsible. WebPageTest also produces a CLS breakdown by element. Start there before trying to fix anything.
Source 1: Images and media without explicit dimensions
The classic CLS source is images that load after the layout is calculated, pushing content down when they finally arrive. Adobe Commerce’s image rendering helps with this when configured properly, but the failure modes are common:
Product images on category pages without width/height attributes. If the image’s space in the layout is not reserved before the image loads, the image arriving causes shift. The fix is explicit width and height attributes on every `<img>` tag, including the responsive image cases. Modern browsers use the dimensions to calculate aspect ratio and reserve space.
Product images with srcset but no consistent aspect ratio. If your srcset images have different aspect ratios at different breakpoints, the browser cannot reserve space until it picks one. Use the same aspect ratio across all srcset variants for any given image.
Magento media gallery on PDP without reserved space. The product detail page gallery typically has a placeholder while the gallery initializes. If the placeholder dimensions do not match the loaded gallery dimensions, you get shift on every product page. The fix is matching dimensions or using `aspect-ratio` CSS to reserve the right shape.
Video embeds without aspect-ratio reservation. YouTube and Vimeo iframes default to no reserved aspect ratio, causing shift when the embed loads. Wrap them in a container with explicit `aspect-ratio: 16/9` (or whatever the embed actually uses).
Source 2: Third-party widgets that inject DOM after page load
Almost every Adobe Commerce store has at least four third-party widgets, and many of them are CLS time bombs:
Trust badges and review widgets. Yotpo, Trustpilot, Stamped, Okendo, and similar widgets typically inject their HTML after the page has loaded. If the host container has no reserved height, the injection causes shift. The fix is reserving a minimum height on the container that matches the typical injected content.
Cookie banners and consent management. OneTrust, Cookiebot, and similar tools inject a banner at the top of the page on first load. The banner pushes the entire page down when it appears, which is one of the largest CLS sources on first-time-visitor pages. Strategies that work: pre-rendered banner with the correct height, or banner positioned absolutely so it overlays rather than shifts content.
Klaviyo and email capture popups. These typically inject above-the-fold content. The fix is the same: reserve space or position absolutely.
Live chat widgets. Intercom, Tidio, Gorgias chat widgets, and similar typically position themselves in a fixed corner and do not cause shift, but the loaders sometimes inject inline content that does. Verify each widget’s actual behavior on first load.
A/B test code. Optimizely, VWO, and Adobe Target inject DOM changes after the page renders. Every test that modifies layout above the fold is a potential CLS source. The mitigation is the test framework’s “synchronous render” or “anti-flicker” mode, which is slower but does not cause shift.
Source 3: Adobe Commerce-specific patterns
Patterns that are specific to Adobe Commerce + Hyvä and not addressed by general CLS advice:
Customer-segment-driven content blocks. Adobe Commerce supports content that changes based on customer segment (logged-in vs guest, customer group, etc.). If the layout block changes height depending on the segment, you get shift the first time the segment data arrives. The fix is ensuring the segment-driven content reserves consistent height across all variants, even when the content itself differs.
Mini-cart updates. Adding to cart updates the mini-cart count and sometimes the mini-cart preview. If the mini-cart preview changes the header height, you get shift on every cart interaction. The fix is fixed-height mini-cart UI that does not resize the surrounding layout.
Hyvä modals and dialogs. Default Hyvä modals overlay content correctly, but custom modal implementations sometimes shift the body. Verify that any custom modal uses position: fixed for the modal itself, not flow positioning.
Product price updates after configurable selection. Selecting a swatch on a configurable product updates the price. If the price text changes length (e.g., from “$99” to “From $99 to $129”), the layout can shift. Reserve consistent width for the price area.
Stock status display. “In stock” vs “Only 2 left” vs “Out of stock” can produce different text lengths, causing shift if the stock area is not reserved width.
Lazy-loaded category page sections. Above-the-fold sections must not be lazy-loaded; doing so causes the most prominent shift on the entire site. Lazy loading should start below the fold.
How to find your specific shift sources
The diagnostic workflow that works:
| Step | Tool | What you are looking for |
|---|---|---|
| 1 | Chrome DevTools Performance with CLS recording | Which elements shifted, when, and by how much |
| 2 | WebPageTest “Layout Shifts” tab | Comparable breakdown with timeline |
| 3 | Real-user monitoring data | Real-world shift percentile, not synthetic |
| 4 | Manual click-through of common journeys | Cart add, login, configurable product selection, swatches |
| 5 | First-visit vs return-visit comparison | Cookie banner and one-time widget shifts only show on first visit |
The first three steps usually identify 80% of the shift sources. The last two steps catch the user-flow shifts that synthetic monitoring misses.
The patterns that hold CLS under 0.1
A well-tuned Hyvä-themed Adobe Commerce store should be hitting CLS under 0.05 on most pages. The discipline that gets you there:
Every image has explicit width and height. No exceptions. Even decorative images get a defined size.
Every third-party widget container has reserved height. Even if the height is “minimum 80px to prevent collapse,” it is set explicitly.
Every dynamic content area has reserved width and height. Prices, stock status, cart updates, and segment-driven blocks all have stable layout footprints.
Web fonts use font-display: swap with metric-matched fallbacks. This is also an LCP optimization but it eliminates the text reflow that contributes to CLS.
A/B test code uses anti-flicker mode or runs below the fold only. Above-the-fold tests are usually not worth the CLS cost.
Lazy loading starts below the fold. Native `loading=”lazy”` is supported in all modern browsers; the configuration is to apply it only to images below the initial viewport.
Bemeir’s Hyvä team treats CLS as a measurement problem first and a fixing problem second. Once you know exactly which elements are shifting, the fixes are mechanical and well-understood. The merchants who stay in “needs improvement” range are usually the ones who have not done the measurement step honestly.
What the data says about conversion impact
The Web.dev research on CLS and conversion shows that stores improving CLS from 0.25 to 0.05 typically see 5-12% conversion lift on mobile. The mechanism is not complicated: when content jumps around as users are about to tap a button, they tap the wrong thing, abandon the flow, or lose confidence in the site. Mobile users are particularly sensitive because their viewport is smaller and the shift is proportionally larger.
For mid-market Adobe Commerce stores doing $20-50M annually, a 5-8% conversion lift from CLS work is meaningful revenue. The work itself is rarely more than 2-3 weeks for a focused engagement, which makes CLS optimization one of the highest-ROI performance investments on Hyvä-themed stores. The discipline is staying focused on measurement and applying the patterns one by one rather than chasing every advice article on the internet.
