Fixing CLS from Responsive Image Swap and Breakpoints

What makes a responsive shift different

An image without any size information shifts at every width, which is covered in fixing CLS from images without dimensions. A responsive shift is more slippery: the page reserves a box that is right at one width and wrong at another. Because most people test on one desktop screen and perhaps one phone, the broken width slips through.

There are four common patterns:

• Art direction with different shapes. A <picture> element shows a wide 21:9 banner on desktop and a taller 4:5 crop on phones, but the only dimensions in the markup describe the desktop file. On a phone the browser reserves a letterbox-shaped space, the tall image arrives, and the content below drops.
• Layouts decided in JavaScript. A component checks window.innerWidth after load and switches from a desktop layout to a mobile one, or a slider measures its slides and sets their height once its script runs.
• Breakpoint styles that arrive late. Critical CSS covers the desktop layout, and the rules for smaller screens sit in a stylesheet that loads afterwards. The page renders with desktop rules on a phone, then reflows.
• Viewport-based sizes that change. A hero set to a height in vh or dvh, or a desktop page where a scrollbar appears after content loads, changes size and moves everything after it.

What they have in common is that the box the browser drew first is not the box the page ends up with, and the difference depends on the screen.

When srcset is safe and when it is not

A plain srcset with a sizes attribute offers the browser the same picture at different resolutions. Every candidate has the same proportions, so the width and height attributes on the <img> are correct whichever file is picked. This kind of responsive image does not cause shifting by itself.

<img src="/img/walk-800.jpg"
     srcset="/img/walk-400.jpg 400w, /img/walk-800.jpg 800w, /img/walk-1600.jpg 1600w"
     sizes="(min-width: 60em) 50vw, 100vw"
     width="1600" height="1000"
     alt="Coastal footpath above the bay">

Trouble starts when the candidates are different crops. That is art direction, and it belongs in a <picture> element with a separate <source> per breakpoint. If a developer has put differently shaped files into a single srcset, the attributes can only be right for one of them. Move the crops into <source> elements, or re-crop all candidates to one shape.

Dimensions on each source

Current browsers accept width and height attributes on each <source> inside <picture>, and use the matching source's numbers to reserve the box. That is the cleanest fix for art direction:

<picture>
  <source media="(min-width: 64em)"
          srcset="/img/sale-wide-2100.jpg"
          width="2100" height="900">
  <source media="(min-width: 40em)"
          srcset="/img/sale-mid-1200.jpg"
          width="1200" height="800">
  <img src="/img/sale-tall-800.jpg"
       width="800" height="1000"
       alt="Autumn sale at Linden Street Interiors">
</picture>

The fallback <img> carries the dimensions for the narrowest crop, because it is used when no media condition matches. Keep img { height: auto; } in your CSS so the ratio controls the height.

A CSS backstop

If your templating makes per-source attributes awkward, or you need to support an older browser, set the ratio in CSS at the same breakpoints the sources use:

.sale-banner img { width: 100%; height: auto; aspect-ratio: 4 / 5; }
@media (min-width: 40em) { .sale-banner img { aspect-ratio: 3 / 2; } }
@media (min-width: 64em) { .sale-banner img { aspect-ratio: 7 / 3; } }

Finding the width that breaks

Start with real-user data, because it tells you which device class is affected. The Core Web Vitals report in Search Console splits results into mobile and desktop, and page groups there often point at a template. If only mobile is poor, test phones first; if only desktop, think about scrollbars, wide art-directed images and sidebars.

1. Open the page in Chrome DevTools with the device toolbar turned on, set the width to a small phone, and enable slow network throttling with the cache disabled.
2. Record a reload in the Performance panel. In the layout shift track, select each shift and check which elements moved.
3. Repeat at each of your CSS breakpoints and a few pixels either side. Shifts that only occur in a narrow band usually mean markup and CSS use different breakpoint values.
4. Run the CLS Debugger and compare the elements it names with what you saw at each width.

To see which art-directed file a picture element chose, and whether the reserved box matched it, paste this into the console after load:

document.querySelectorAll('picture img').forEach((img) => {
  const box = (img.clientWidth / img.clientHeight).toFixed(3);
  const file = (img.naturalWidth / img.naturalHeight).toFixed(3);
  console.log(img.currentSrc, 'box', box, 'file', file,
    box === file ? 'ok' : 'MISMATCH');
});

A mismatch after load usually means object-fit is cropping, which is fine; a mismatch you can see as a jump during load means the reserved ratio was wrong.

The fix, step by step

JavaScript that rearranges the page

A large share of responsive shifts are not about images at all. They come from code that decides the layout after the first paint.

Mobile and desktop components chosen in script

In server-rendered apps, the server cannot know the screen width, so it renders a default, often the desktop navigation. When the page hydrates in the browser, a hook reads the width and swaps in the mobile menu. The header changes height and the page moves. The robust answer is to send markup that works at every width and let CSS decide what is visible:

<nav class="nav-desktop">…</nav>
<nav class="nav-mobile">…</nav>

.nav-mobile { display: block; }
.nav-desktop { display: none; }
@media (min-width: 60em) {
  .nav-mobile { display: none; }
  .nav-desktop { display: flex; }
}

Framework-specific patterns for this, including hydration mismatches, are in CLS in React and Next.js.

Sliders and carousels that measure themselves

Many carousel scripts show all slides stacked on top of each other until they initialise, then measure the first slide and set the track's height. On a phone, where a slide might be twice as tall as on desktop, the jump is large. Give the carousel container an aspect-ratio or min-height per breakpoint, and hide slides after the first with CSS until the script is ready, so the uninitialised and initialised versions take the same space.

Equal-height scripts

Older themes use JavaScript to make cards in a row the same height. On narrow screens, where cards stack in one column, the script may still run and change heights after load. CSS grid and flexbox give equal heights without any script; remove the old code.

Viewport units, toolbars and scrollbars

The scrollbar issue is easy to miss. On Windows and some Linux desktops, scrollbars take up real width. A short page renders without one, then a late block of content makes the page tall enough to scroll, the scrollbar appears, the page narrows by around 15 pixels, text rewraps and blocks change height. Reserving the gutter from the start removes that reflow. Overlay scrollbars on macOS and phones take no width, so you will not see this on those devices.

Keeping responsive layouts stable

• Keep a single list of breakpoints. Define them once, in CSS custom media or design tokens, and use the same values in markup media attributes, stylesheets and scripts.
• Treat art-directed images as a design decision. When a designer supplies different crops, record the ratio for each breakpoint alongside the files so developers can add matching dimensions.
• Test at awkward widths. Include a width just below and just above each breakpoint in your testing checklist, plus a common small phone and a tablet in landscape.
• Watch both device classes. Search Console reports mobile and desktop separately. A redesign that helps one can harm the other.

For the scoring rules behind all this, and how to rank shifts by impact, see the CLS Guide.