0

I'm optimizing the speed of a WordPress website (on mobile only for the moment), with success except for CLS. The CLS became extremely high after optimizing CSS delivery (with WP-Rocket), but I don't see any layout shifts, even when I use Dev Tools (performance test). (on mobile)

Here’s the example : https://trustmyscience.com/israel-a-pratiquement-eradique-la-covid-19/

  1. Results here, with CSS delivery optimization

So it seems to be an invisible layout shift, that Lighthouse perceive as a real layout shift. Lighthouse shows me the problem comes from <div class="entry-content body-color clearfix link-color-wrap progresson">. So, it seems to be related to some "wrapping" of the all article content, that maybe shifts into the background (without being visible), because of some CSS rules maybe ?

  1. Here, the element with the highest layout shift
  2. The element with the highest layout shift (detail)

When I deactivate CSS delivery optimization, CLS go back to almost 0 (but LCP is too high).

  1. Results WITHOUT CSS delivery optimization

I need this CSS delivery optimisation because of LCP importance, but I also now need to solve this issue because of CLS introduction in Core Web Vitals, and need to find what Lighthouse is detecting as a LS. Also, maybe, Lighthouse needs a correction for that ? As it isn't a visible layout shift...

Do you have any idea on how to solve this ? Or do you think I need to reach LS developers to show them this ?

Thank you in advance for your help.

Regards,

P. J
  • 1
  • 2

2 Answers2

2

You might gain a bit in performance by self-hosting the fonts instead of making a call to the Google Fonts API, but fonts are not the main issue here. Javascript is.

There is a lot of Javascript on this website, so the main thread is busy downloading it, parsing it and executing it.

I ran both Lighthouse (with Clear Storage and Simulated throttling enabled) and WebPageTest with a Moto 4G profile.

As you can see from Chrome DevTools and WebPageTest, roughly 56% of the processing time spent on the main thread is due to scripting. Do you really need all of that Javascript?

Here is what I noticed in the Chrome DevTools Performance panel:

Chrome DevTools Performance panel showing JS requests

WebPageTest main thread processing breakdown

CLS is basically the sum of all unexpected layout shifts that occur on a page. As you can see from the dashed orange line in the chart below, the 4 .woff2 font files contribute to the CLS: the first layout shift occurs as soon as the fonts are fetched.

first layout shift caused by fonts

But as I said, I would focus on removing all unnecessary Javascript. In particular, I would examine third-party JS like the one coming from choices.consentframework.com, which takes 1730ms to load and represents 25% of the content size (see below).

choices.consentframework.com takes 1730ms to load

choices.consentframework.com is 25% of the content size

After JavaScript, focus on the images.

The Performance panel in Chrome DevTools shows a lot of requests for images. Are you fetching only the images that are in the viewport, or all the images that are on the page?

a lot of requests for images

Most of these images are WebP and seem already optimized, but there are a few GIFs, which are really bad for performance. It seems that these GIFs are served by https://www.viously.com/ (I guess it's an Ad Server, it's the first time I see it).

GIFs are bad for web performance

Last but not least, double-check that all of your <img> and <video> have size and width attributes set. Images and videos are replaced elements with intrinsic dimensions, and forgetting to set sizes for images in your HTML is a common cause of layout shifts.

See also this article by Addy Osmani for a few more tips on how to optimize CLS.

layout shifts

jackdbd
  • 4,583
  • 3
  • 26
  • 36
  • Wow ! Thank you so much for that ! It didn't solve the CLS issue, but it has motivated me to reduce all of that js. I did a first attempt and the total blocking time is now way better (always on green). LCP is now also reduced. Hope a "CLS expert" will join this thread too now ^^... – P. J Apr 27 '21 at 07:51
  • CLS is a combined metric invented by Google to give you an idea of all the layout shifts (aka layout reflows) that could potentially be avoided. Not all layout shifts, because with no layout shifts the browser would not render anything. CLS is not an "event" you can easily spot in Chrome DevTools (like DOMContentLoaded or TTFB). That's why it's hard to pinpoint exactly the main reason for a high CLS. For a nice introduction to CLS see also https://web.dev/cls/. And for a list of all the things that could cause a layout shift see this: https://gist.github.com/paulirish/5d52fb081b3570c81e3a – jackdbd Apr 27 '21 at 09:11
0

The CLS is visible, it's the font.

Don't you notice that when you visit the page, the text gets resized? That's a common cause of CLS.

How to solve?

Serve your fonts locally. Do not use any plug-in like OMGF. Do it manually.

  1. Download the fonts. Choose 2 fonts, one for body, another for headings. You won't need bold, italic, or bold+italic fonts. These will be applied by user's browser.
  2. Convert to woff2 (only woff2 is enough, didn't face any issues)
  3. Upload it to your server
  4. Add font face CSS to declare the fonts
  5. Apply the fonts using CSS elements
  6. Disable Google fonts if you're using any WP theme or builder
  7. Preload the fonts

This will solve the CLS problem, will also reduce the Total Blocking Time.

Fahim
  • 308
  • 1
  • 3
  • 10
  • Fonts are adding a very low CLS here, as you can see if you do the test on your own. This is not the cause of this very high CLS here. Have you read the whole post ? – P. J Apr 24 '21 at 13:37
  • I'd say to first solve the font issue. And about the Critical CSS issue, you've to exclude the CSS selectors that are causing the CLS. When I visited your site, I think the critical CSS was turned off. – Fahim Apr 25 '21 at 16:10
  • Of course I appreciate that. I did this for fonts in the past and it didn't change a lot, so I'll do it again but first, I need to solve this CLS issue ;-). Yes, I need to exclude the CSS causing that from async but for the moment I don't know exactly how and for how many of them. I will let you know on this thread when I find the solution. – P. J Apr 27 '21 at 07:55