1

I try to optimize the whole Pagespeed of this page but I can't get the CLS under 0.1 on mobile. I really don't know why as I use critical css, page-caching and font-preloading and I cant reproduce the behaviour in tests.

https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwww.birkengold.com%2Frezept%2Fselbstgemachte-zahnpasta

Tested with an simulated Galaxy S5 on 3G Fast. https://www.webpagetest.org/result/210112_DiK9_256ca61d8f9383a5b927ef5f55644338/

In no Scenario I get somewhere near the 0.1 in CLS.

Rick Viscomi
  • 8,180
  • 4
  • 35
  • 50
Axos
  • 148
  • 2
  • 6
  • Your CLS from the link you gave just came out at 0.04 run and 0.027 on a second run for PSI and you linked to a test that has a CLS of 0.001 for webpagetest, I am not sure what you are asking as both of those are under 0.1 – GrahamTheDev Jan 12 '21 at 12:54
  • The tests are totally fine and the reason why I can't understand the field data. The field data for this explicit page's CLS is at 0.16s and for the whole page (origin) on 0.12s. – Axos Jan 12 '21 at 17:49
  • ok put you an answer down that should hopefully explain the difference and how to track it down in the real world. Also just for clarity 'origin summary' is all pages across the site that have sufficient data in the CrUX dataset, 'field data' is for this page only. Pretty sure you have that down but the comment above made me want to double check (as you said whole page for origin). – GrahamTheDev Jan 12 '21 at 18:38
  • Yes i know how the origin summary works :) I just pointed it out because the most of our the pageviews come from pages with exactly this template. So the "origin data" kind of speaks for the rest of the recipes too. Thanks for your answer. I knew about the library already but i thought if I use critical css without lazyload above the fold and that loads fine on all screen sizes, I could maybe solve it without further investigations and someone maybe could point me to my mistake :) I will give the web vitals library a try then. – Axos Jan 13 '21 at 11:10
  • one thing to check is that your [images have defined width and height attributes](https://stackoverflow.com/a/65077326/2702894), this is often a cause people overlook for CLS that happen further down the page. Good luck with the project, hope you find the cause! – GrahamTheDev Jan 13 '21 at 11:13
  • Thats right. As they are responsive i chose to add padding-bottom with the aspect ratio on the wrapping-container and positioned the image inside absolute. So that should definitely not be the reason. – Axos Jan 13 '21 at 11:55
  • Just so you know the CLS is obvious when the page loads, it looks like your inline CSS doesn't have all critical styles as the buttons change shape (get larger) and your "slider" at the top that displays products starts with one product showing then shows two products (so I am guessing you need to rework how the JS for that operates). This was easy to spot using [the techniques in this question and answer](https://stackoverflow.com/q/62751471/2702894) – GrahamTheDev Jan 14 '21 at 08:13
  • 1
    As I said I did investigate the issue deeper with your information and found out that most of my cls issues (90%) comes from my consent popup which loads on userinteraction. So there I couldn't see the issues on the generic tests. Thank you for your help and pointing me in the right direction! – Axos Jan 21 '21 at 14:52

1 Answers1

1

Field Data and Origin Summary

Field data and Origin Summary are real world data.

There is the key difference between these metrics and the synthetic test that Page Speed Insights runs.

For example: CLS is measured until page unload in the real world, as mentioned in this explanation on CLS from Addy Osmani who works on Google Chrome.

For this reason your CLS can be high for pages if they perform poorly at certain screen sizes (as Lighthouse / PSI only tests one mobile screen size by default) or if there are things like lazy loading not performing well in the real world and causing layout shifts when things load too slowly.

It could also be certain browsers, connection speeds etc. etc.

How can you find the page / root cause that is ruining your Web Vitals?

Let's assume you have a page that does well in the Lighthouse synthetic test but it performs poorly in the real world at certain screen sizes. How can you identify it?

For that you need to gather Real User Metrics (RUM) data.

RUM data is data gathered in the real world as real users use your site and stored on your server for later analysis / problem identification.

There is an easy way to do this yourself, using the Web Vitals Library.

This allows you to gather CLS, FID, LCP, FCP and TTFB data, which is more than enough to identify pages that perform poorly.

You can pipe the data gathered to your own API, or to Google Analytics for analysis.

If you gather and then combine the web vitals information with User Agent strings (to get the browser and OS) and the browser size information (to get the effective screen size) you can narrow down if the issue is down to a certain browser, a certain screen size, a certain connection speed (as you can see slower connections from high FCP / LCP figures) etc. etc.

GrahamTheDev
  • 22,724
  • 2
  • 32
  • 64