CLS Issue: More Than 0.1 (Mobile): What It Means and How to Fix It

"CLS issue: more than 0.1 (mobile)" means that for a group of similar pages on your site, more than a quarter of real mobile visits saw the layout jump around enough to score over 0.1 for Cumulative Layout Shift. Search Console didn't run a test. It is reporting what actual Chrome users experienced over the last 28 days, including everything that happened after the page finished loading. That last part is why your own tests so often come back clean.

Here is what the score measures, why Lighthouse misses it, and how to find the element that's actually moving.

What the warning actually means

Search Console's Core Web Vitals report uses real-user data from the Chrome UX Report (CrUX), and sorts each group of URLs into one of three CLS bands:

• Good: 0.1 or less.
• Needs improvement: over 0.1, up to 0.25. This is "CLS issue: more than 0.1".
• Poor: over 0.25. This shows up as "CLS issue: more than 0.25".

Three details in how the report works explain most of the confusion:

1. It grades the 75th percentile. Google describes Group CLS as "the lowest common CLS for 75% of visits to a URL in the group." If the slowest-settling quarter of visits shift enough, the whole group fails.
2. It grades groups of pages, not single URLs. Search Console groups similar pages, such as all your product pages, and gives the group one status. The example URL is one member of that group, not necessarily the worst one.
3. Mobile and desktop are graded separately. The "(mobile)" in the label tells you which report you're in.

CLS is the one Core Web Vital where mobile does better than desktop. The 2025 Web Almanac found 81 percent of mobile pages have a good CLS, against 72 percent on desktop. So a mobile CLS warning puts you in the minority, which usually means something specific on your pages is moving, rather than a general "the web is slow on phones" problem.

How CLS is scored

Every time a visible element moves without the visitor causing it, the browser gives that shift a score:

layout shift score = impact fraction × distance fraction

The impact fraction is how much of the viewport the moving elements touch. The distance fraction is how far they moved, relative to the viewport. A big block moving a long way scores high. A small badge nudging a few pixels barely registers.

Shifts are then grouped into "session windows": bursts of shifts with less than one second between each, capped at five seconds per window. Your CLS is the score of the worst single window in the whole visit, not the sum of every shift. So one bad moment is enough to fail.

Two kinds of movement don't count:

• Shifts within 500 milliseconds of a tap, click or key press. If a visitor opens an accordion and the content below moves down, that's expected. Note that scrolling does not count as input, which matters below.
• Animations done with CSS transform. Moving an element with transform: translate() doesn't change layout, so it never causes a layout shift.

Why your own test probably passes

Lighthouse and the PageSpeed lab score only watch the page load. Google says outright that lab CLS "may be less than what real users experience in the field." CrUX measures the whole visit. That gap is where most CLS warnings live:

• Shifts during scrolling. A sticky header that changes height as you scroll, a "back to top" bar that pushes content, a lazy-loaded section below the fold that arrives without reserved space. None of it happens in a load-only lab run, and because scrolling isn't counted as input, all of it counts in the field.
• Late arrivals. Cookie banners, promo bars, chat widgets and review carousels that load a few seconds in, after the lab run has decided the page is done.
• Slower connections. On a fast connection the font and images may arrive before first paint. On a patchy mobile network they arrive after, and the page reflows in front of the visitor.

So check the field data first. In PageSpeed Insights, the "Discover what your real users are experiencing" section at the top is CrUX. If that fails and the lab score passes, the problem is usually something that happens after load. The wider gap between lab and field has its own article.

Step 1: Find the element that moves

There are no CLS subparts to read off a report, so you need to catch the shift yourself. Three ways:

• DevTools Performance panel. Record a trace with network and CPU throttling on, then load the page and scroll it the way a visitor would. The Layout Shifts track groups shifts into clusters, and clicking one shows which elements moved. The layout shift culprits insight lists the likely causes, such as an unsized image or a late web font.
• DevTools live metrics. The Performance panel's landing view shows CLS updating live as you interact, which is the quickest way to find shifts that only happen after load.
• Real-user attribution. The attribution build of the web-vitals library reports largestShiftTarget (a selector for the element that moved most), largestShiftTime, and the document's loadState when it happened. Send those to your analytics and you'll know which element moves for real visitors, and whether it happens during load or long after.

One caution from Google's own guidance: Lighthouse's CLS audit often lists the elements that were pushed, not the element that did the pushing. If it flags your product grid, look at what loaded above the product grid.

Step 2: Give images and embeds a size

This is the most common cause by far. The 2025 Web Almanac found 62 percent of mobile pages have at least one image without dimensions, and the median page has two. Without a size, the browser reserves no space, then shoves everything down when the image arrives.

The fix is Google's simplest instruction: "Always include width and height size attributes on your images and video elements." Browsers use the two numbers to work out the aspect ratio and reserve the right space before the image loads, even when CSS makes the image responsive. For elements that aren't images, CSS aspect-ratio does the same job.

The same applies to anything embedded: ad slots, YouTube iframes, maps, Instagram embeds and review widgets. Reserve the space with min-height or aspect-ratio in the initial layout. If an ad slot sometimes comes back empty, keep the placeholder anyway: collapsing reserved space causes a shift too.

Step 3: Stop injecting content above what people are reading

Anything that appears near the top of the page after load pushes everything else down, and content injected near the top shifts more of the page than content injected lower down. The usual suspects:

• Cookie and consent banners inserted at the top of the page, rather than overlaid at the bottom.
• Promo and announcement bars ("Free shipping this week") rendered by JavaScript after the header.
• Personalised blocks ("Recently viewed", "Welcome back") swapped in once a script has decided who you are.

Either reserve their space in the server-rendered HTML, or overlay them with position: fixed so they sit on top of the page instead of in its flow.

Step 4: Check anything that changes size on scroll

This is the one most guides skip, and the one most likely to explain a field warning your lab tests can't reproduce. A sticky header that shrinks or grows when you scroll, or that switches from normal flow to position: fixed part-way down, can move the entire page by a header's height. Since scrolling isn't user input as far as CLS is concerned, every one of those moments counts.

The fix is to keep the space the header occupies constant. Reserve its full height in the layout (a fixed-height wrapper works), and animate the visible part with transform rather than changing height, top or padding. A header that looks like it shrinks but is really scaling or sliding with transform shifts nothing.

Step 5: Tame web fonts

When a web font arrives after the fallback has already been painted, the text reflows: different letter widths, different line breaks, everything below moves. Your options, from Google's guidance:

• font-display: optional. The font is only used if it's ready by first layout, so it can never cause a reflow. The trade-off is that visitors on slower connections may never see your brand font on that page view.
• Metric-matched fallbacks. Keep font-display: swap, but use size-adjust, ascent-override, descent-override and line-gap-override on the fallback @font-face so it takes up the same space as the web font. The swap still happens, but nothing moves. This is what this site does.
• Preload the fonts used above the fold, so they arrive sooner and the window for a swap is shorter.

Step 6: Make the page eligible for the back/forward cache

When a visitor taps back, a page restored from the browser's back/forward cache appears instantly and fully laid out, and Google resets its CLS to zero for that visit. Google calls bfcache eligibility "a highly effective technique for keeping CLS scores low." The two most common blockers are unload event handlers and Cache-Control: no-store on HTML. The Web Almanac found 23 percent of sites now send no-store, which Firefox and Safari treat as a reason not to cache the page. Chrome DevTools has a back/forward cache test under Application that tells you exactly what's blocking it.

Step 7: Validate the fix in Search Console

Once the fix is live, open the issue in the Core Web Vitals report and start tracking. That doesn't trigger a recrawl. It starts a 28-day monitoring period of real-user data, and the issue counts as fixed only if no URL on the site shows it for the whole period.

Expect a slow feedback loop. Because CrUX is a rolling 28-day window, the warning can stay up for weeks after a fix that worked. And if you fix a "more than 0.25" issue and a "more than 0.1" warning replaces it, that's the group moving from poor to needs improvement. Progress, not a new problem.

The short version

1. Trust the field data. If Search Console says the group fails, a clean Lighthouse run doesn't change that.
2. Find the element that moves, in a throttled trace that includes scrolling, or with web-vitals attribution from real visitors.
3. Size every image and embed with width and height, or aspect-ratio.
4. Reserve space for anything that arrives late, or overlay it.
5. Keep sticky headers a constant size, and animate with transform.
6. Match your fallback font metrics and make the page bfcache-eligible.
7. Validate and wait 28 days.

If Search Console is flagging the other two metrics as well, see what "LCP issue: longer than 2.5s (mobile)" means and how to fix "INP issue: longer than 200ms (mobile)". Shopify themes have their own set of usual causes, as does WordPress. And if you'd rather have the moving element tracked down and fixed for you, that's what the performance fix service does.