CLS issue

Hi thomastolkien,

Thanks for your excellent description. I will try to find the time to reproduce it in the next days.

Thomas

Hi @thomastolkien,

I tried to reproduce this, but couldn’t.

The 2021 default theme does not have widgets in the viewport, so that should not measure anything.

I tested a theme that has a widget in the viewport on desktop and there was nothing wrong with it either.

Can you reproduce the issue using an official Google check? I am using the Lighthouse feature that is built into Chrome.

Thanks,
Thomas

Hi,

I am testing these kind of issues as well. A very good tool to monitor the CLS is the Web Vitals chrome-extension: https://chrome.google.com/webstore/detail/web-vitals/ahfhijdlegdabablpippeagghigmibma

You can also activated it in incognito mode and see the CLS change while scrolling the page.

I can see CLS-errors while scrolling on my end as well.

Regards, Yuri

• This reply was modified 3 years, 8 months ago by YuriV.

I need to see the issue in action. @yuriv if you can provide your URL then that would help.

Thanks,
Thomas

Hi Thomas, thanks for the reply. You could check for example this page: https://histobron.nl/wilhelmus-alle-coupletten-van-het-volkslied/

• No CLS warning in the Chrome extension when the page opens
• No warning when scrolling down
• No warning when the user reaches the sticky widgets
• WARNING when scrolling up again, exactly on the place where the sticky widgets end

Regards, Yuri

Thanks, @yuriv.

From what I have read so far, the CLS check that Google might use for the web vital score does not scroll below the fold. So I don‘t believe this should be an issue – and I am saying this as a publisher who actively uses Fixed Widget.

If you see the CLS score increasing on a check like https://web.dev/measure/ due to the fixed widget then I am happy to take another look at that.

Even if this would somehow affect the CLS score in the future, I don’t have an idea on how to “fix” it except for not using fixed elements at all. Though, I am open to ideas.

Thanks,
Thomas

Hi Thomas,

Thanks for the reply. I was alarmed by Google Search Console. We have a lot of reports about CLS errors there. We then optimized the page so that the CLS errors disappeared from the online reports of web.dev and Google Pagespeed. Case resolved we thought. However, Google Search Console continues to give errors after weeks, so we looked further and used the mentioned chrome extension. After scrolling, CLS-errors do indeed appear (below the fold, when the page reaches the sticky widget), but if they don’t count, the errors at Google Search Console should eventually disappear. Unfortunately, they have a long delay in their results. We’ll wait a bit longer.

Regards, Yuri

Hi Yuri,

I also just checked in the Search Console and have the same problem. I did some fixes a while ago and the values should be good now – according to the web.vitals test. But they were not updated in the Search Console, yet.

The original poster @thomastolkien hasn’t come back here and I don’t want to bother him with notifications, so I would suggest you open a new thread when you have some news.

Thanks,
Thomas

Unfortunately below the fold CLS scores absolutely do count, and this is why we are all seeing CLS errors in Google Search Console. Specifically the whole page ClS, and the user’s lifetime experience on the page, count towards the “field” and “origin” scores. See this thread on Google webmasters:
https://support.google.com/webmasters/thread/100784547?hl=en

I can also confirm that 28 days after removing the plugin, Google search console reports all CLS errors resolved.

It’s a great plugin, but sorry to say that sadly it’s no longer compliant for Google’s Core Web Vitals requirements. Really hope the plugin can be fixed.

• This reply was modified 3 years, 8 months ago by thomastolkien.

Thanks for your feedback, @thomastolkien.

Maybe there are two technologies just not compatible anymore. If Google does not like fixed elements then maybe publishers need to decide for either of them.

Or maybe I am missing something. What would you consider a solution?

I will also keep investigating.

Thomas

The CLS seems to be caused by how jquery is used by the plugin. If you use the record function on dev tools you can see how the sticky widget is replaced by a hidden widget using javascript when the user returns to the top of the sidebar. This causes the CLS jump.

A solution might be to use just CSS. CSS sticky elements don’t cause CLS. However, they can be much more difficult to implement in sidebars, containers and divs – so that would be the challenge. Vanilla javascript rather than jquery might be possible, but a pure CSS solution would likely resolve the issue.

@webzunft — good reading here regarding CLS:

https://stackoverflow.com/questions/66691747/cls-issue-only-as-a-part-of-field-data-how-to-diagnose-it/66692021#66692021

It looks like Google is now measuring CLS using field data and it tracks the entire session, not just the initial viewport. So, if the sidebar or header is sticky, while you scroll, you will rank up negative CLS…

One option might be moving sticky elements to CSS:Sticky.

https://stackoverflow.com/questions/62682709/why-does-cumulative-layout-shift-differ-between-pagespeed-insights-and-search-co?rq=1

Lab tools like Lighthouse have to define a shorter window because they are focused on the experience during page load and optimize for delivering information about the experience quickly. Field data is able to take a more holistic view of the user-experience, which could include shifts caused after a page has loaded and the user has scrolled down to other interactions contributing to CLS.

• This reply was modified 3 years, 7 months ago by Steve.

Thanks @skrause.

All information provided here combined allowed me to reproduce an issue and play with possible solutions. Using position: sticky might be the way to go. At least it seems neutral in regards to CLS.

Please note, that Fixed Widget is not a commercial project. I am managing it in my free time. I have not yet an idea how to handle the rewrite in terms of available time and the release strategy. Previous options might not work, especially if the release should happen in a foreseeable future.

I am happy to look into further issues or questions in a new thread.

Thanks,
Thomas