Unusual rapide and high increase of CLS for mobile

[Jan Harmening]

Within view days the CLS increased from 0.12 to 0.37 although we didn't make any change on server or site structure on our domain https://auswandern-info.com/ 

Does anyone have an idea why and what to do?

[❄ Johannes Henkel]

Hi!

I'll just scribble my thoughts - some may be obvious (sorry) and others are welcome to chime in and correct. :-)

1) The graph you sent shows a deterioration in CLS for the origin (includes all URLs aggregated together); starting sometime in April.

CrUX uses 28 day collection periods, so I'm looking toward the beginning of the upslope. To distinguish between a single URL and Origin I use the controls in CrUX Vis to toggle between homepage and origin, but CrUX has very little URL data for this site.

2) The deterioration happens for form factor phone, but not for desktop.

I'm switching between Phone and Desktop to see how the P75 graph for CLS changes.

From CrUX data, it's not possible to see which page(s) in the origin have the problem. If you have your RUM data with the Core Web Vitals measurements you could probably query for it. Or, if you have a Search Console account for this, you could look at the Core Web Vitals Report (https://support.google.com/webmasters/answer/9205520?hl=en) to see if it gives you examples for pages that perform poorly with CLS on phone.

To be clear I don't have access to either data - but I poked a bit. I think the country specific pages are OK-ish with CLS. But as an example (this by itself may not move the needle for the entire origin), maybe the job search page is not, according to PageSpeed Insights:

https://pagespeed.web.dev/analysis/https-auswandern-info-com-jobsuche/ee1rj6f0ke?form_factor=mobile

Note that the upper part of the report is the CrUX data for the origin, which we already knew, it's not specific to the job search page. The lower part runs lighthouse for that specific page, so it's a lab measurement, not from real users, but it has a section that points out the "Layout Shift Culprits". You could start there, maybe, and if needed read the article on "Optimize CLS" - https://web.dev/articles/optimize-cls

Chrome DevTools would be the place to dig deep. Relevant article: https://web.dev/articles/debug-layout-shifts#devtools

Good wishes!

On Tue, Jun 24, 2025 at 1:50 AM Jan Harmening <jan.iv...@gmail.com> wrote:

Within view days the CLS increased from 0.12 to 0.37 although we didn't make any change on server or site structure on our domain https://auswandern-info.com/ 

Does anyone have an idea why and what to do?

--
You received this message because you are subscribed to the Google Groups "Chrome UX Report (Discussions)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chrome-ux-repo...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chrome-ux-report/a8b20fac-fb95-464f-8352-e25007375cacn%40chromium.org.

[Jan Harmening]

Thanks for the detailed answer. 
But as I realize, none of the mentioned possibilities are hitting the reason. 
I give just one example: Page https://auswandern-info.com/frankreich/ has on Mobil bad CLS 0f 0.36 in Core Web Vitals. But when you check the actual CLS, it is good enough with 0.034 (see screenshots). 
I test it on many pages since many weeks. Always same results: Actual CLS is good, but on CWV it is bad. It makes no sense. 
Therefore, I think something is wrong with CrUX

[Jan Harmening]

And the from you mentioned and tested page https://auswandern-info.com/jobsuche/ is the only page that is built on a feed of another website. There the CLS must be slow because it draws in all data from another website.
Please make tests of other sites. On most of them you will see the same result for Mobile: bad CLS on Core Web Vitals and good CLS in todays test. Months ago we have speeded up our website, but CWV shows bad results.

[❄ Johannes Henkel]

So, I think it's likely that the main discrepancy between the lab measurement in PageSpeed Insights / Lighthouse comes from these tools only measuring the layout shifts that occur in a short window during / after loading the page, but CrUX takes the shifts after that into account as well. The principle of the session windows that we use for the value shown in CrUX is explained here: https://web.dev/articles/cls#what-is-cls

This sort of thing applies to all the pages, not just the one that I pointed out - without knowing the relative traffic that these pages get, it's difficult to say which page is the best optimization target, because the CLS origin values in the field data accumulate per page load.

If you collect core web vitals with a RUM, you'd also get the shifts taken into account that happen after loading, while users click and scroll around and hang out on the pages, so aggregate values from that would allow you to more easily find the most worthwhile pages to optimize.

But if you have a hunch and just want to try optimize a specific page the article about debugging layout shifts with DevTools (https://web.dev/articles/debug-layout-shifts#devtools) gives you pointers for how you can measure them while you click around the page, and if you have common infrastructure that ends up applying your fixes across the site, then that could be a worthwhile starting point as well - e.g. look for some layout shift you can see in the DevTools live view while you click around the site and try to get rid of it, and rinse and repeat.

I don't know whether there's more to it - perhaps others can add or correct. I think it's a good cause to work on it because CLS does measure stuff that reflects user experience so it should help the users visiting your site.

[Barry Pollard]

Not sure if this is your main problem, but here's one example of bad CLS:

1) Go to the home page: https://auswandern-info.com/

2) Scroll to the bottom of the page

3) Open DevTools performance panel

4) Refresh the page

5) Note the bad CLS

This means any deep links to places further down the page will suffer from CLS. I'm not sure if you've a reason for people to load pages further down the page more recently (e.g. a marketing campaign with a deep link, or a popular page that went viral that happens to link further down).

From a quick look it appears to be due to late loading fonts. So it's worth debugging what what originally loads on Android (as we only have Core Web Vitals data from Android mobile phones).

The other thing I noticed is that your Core Web Vitals recently crossed the 75% "good" threshold and 

https://cruxvis.withgoogle.com/#/?view=visstability&url=https%3A%2F%2Fauswandern-info.com%2F&identifier=origin&device=PHONE&periodStart=0&periodEnd=-1&display=both

So perhaps this was always a problem for the poor users, but you've only recently had enough of such visitors (perhaps for the reasons above?) for this to start affecting your 75th percentile numbers?

Other than that, assuming you don't have RUM data to help explain this, I would suggest (as Johannes implied) to look at your analytics, see which pages are the most popular, and see if those pages have CLS issues.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chrome-ux-report/CAO3HAxzkaneav%2BGvg4nbjKJ4p9rCOfSXBP65Bj8Er-H0Qi5OKA%40mail.gmail.com.

[Jan Harmening]

Thank you for your answers. I will discuss it with our web developer