CLS issue on metrics but not on page - can that be sorted out?

Hello,

I have tested my website with both PageSpeed Insights and Webpagetest and they give a high CLS metric - exactly the same. The problem here is that there is no actual layout shift taking place, especially in viewport area. Or below viewport area. Or way down below the viewport.

According to Page Speed, it is a footer json background animation that counts as CLS (it isn’t). Even worse it gets a very high value: 1.

Such animations as background in some sections are quite usual. Mine is at the footer. The animation script comes from here:

How am I supposed to fix a “layout shift” that isn’t happening?

1 Like

Do you have a WebPageTest test ID you can share? We report shifts that Chrome itself is surfacing and it’s entirely possible that Chrome may be reporting something that isn’t visually shifting.

1 Like

https://www.webpagetest.org/result/210413_AiDcX9_80cb05000429bbc0c4491a89f133b74c/

https://www.webpagetest.org/result/210413_BiDcFB_40f7924bfaff8b20446cdfb6f6155b46/

Same CLS issue in every page of the site.

1 Like

Ok, this is a funky one. :slight_smile:

You’re right—I see no visible layout shift occurring. I looked at the JSON results for your tests (https://www.webpagetest.org/jsonResult.php?test=210413_AiDcX9_80cb05000429bbc0c4491a89f133b74c&pretty=1), which have all the detailed information from Chrome about the layout shifts to see confirm what is being reported as causing the shift and it’s div#particlesjs-4980 (which looks like the same one you were seeing in the PS report).

Looking at the waterfall, the shift happens right after some JS executes.

So I decided to test in Chrome with JavaScript disabled and compare what happens with that element. Before your JavaScript executes, that element takes up the full viewport (because of the absolute positioning):

After JavaScript executes, it moves down the the footer where it belongs. Since it’s moving a full viewport, that’s why you’re getting a score of 1.

That being said, this feels like a bug in Chrome. There’s nothing visually shifting here. I’d suggest filing a bug with Chrome (https://crbug.com/new) and adding your WebPageTest runs for reference.

1 Like

Actually, ignore me! :slight_smile: I forgot there was some work done in Chrome (v90) around fixing invisible element shifts. Running this test in Canary shows the shift is completely gone. WebPageTest Test Result - Dulles : www.ast....org/zodiakos.html - 04/14/21 14:20:59

So…hang tight as they’ve addressed this for you already.

1 Like

Thanks a lot for taking the time to look into this.
I thought it could be a bug. I’m glad to hear they’re fixing it. Do such fixes also extend to google’s PS?

1 Like

Yes, when it gets fixed in Chrome it bubbles through to all of the tools that report it (they all use Chrome’s internal reporting). For the field data for web vitals there is a 28-day rolling window where it will lag even after the browser is released to the public.

For Page Speed Insights lab data, it will depend on when they update to use Chrome 90.

1 Like