CSS content-visibility:auto causing higher CLS ?

[王康文]

hi

As we have been striving to improve our INP (Interaction to Next Paint) metric recently, we started to implement the content-visibility: auto CSS property to defer rendering some offscreen and non-visible elements, thereby skipping rendering work on several offscreen interactive elements. However, after nearly two months of testing, it appears that setting this CSS property on offscreen non-visible elements has drastically impacted our CLS (Cumulative Layout Shift) score. Even without scrolling to those elements, we detected a higher CLS score upon page load, despite the absence of any visible shift region. Yet, the CLS metric showed an increase.

We are seeking insights from others who may have encountered similar issues or perspectives on this matter. Perhaps we have missed something regarding the proper implementation of content-visibility: auto. It's worth noting that this issue only occurs in our desktop metrics, not on mobile.

If anyone has any insights or has faced comparable challenges, we would greatly appreciate your feedback. Our goal is to understand and address this unexpected CLS score increase caused by the content-visibility: auto implementation.

Here is some example site: 
https://stars.udn.com/star/story/10088/7970442 

p/s: we have temporary unset global * {content-visibility: unset !imporatant;}  to monitor if any improvment on webvitals field data. 

[Michal Mocny]

I think that content-visibility requires useful intrinsic size property values or else it will induce layout costs (and potentially trigger cls) when scrolled into view.  Are you using those?

You mention that this also affects CLS even without scrolling.  I don't think it is expected to have effects above-the-fold since you should do full layout for viewport intersected content.  However, I wonder if there are effects with render-blocking content, or perhaps it's possible that very early "layout thrashing" within a single animation frame where perhaps we measure layout shifts even for above-the-fold content?  However, I wasn't actually able to reproduce such hypotheticals.

I tried the link you shared and I did observe some CLS in the sidebar content (the ads on the right), but I can clearly see a real shift down when one of the ads loads.  There are some very very small shifts beyond this and they might be related to font loading as I do see some flickering of text.  I couldn't reproduce a large "non-observable" shift for above-the-fold, as far as I can tell at least.  If you could help provide repro steps, or record it happening, or best is a reduced test case rather than a complex live site -- that might help.

(I also was unable to reproduce CLS during scrolling on that page, but I haven't tested for long).  (I am testing on MacOS desktop.  Is this perhaps limited to Android?)

--
You received this message because you are subscribed to the Google Groups "web-vitals-feedback" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-vitals-feed...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/web-vitals-feedback/dbf26bd7-e88b-4938-970c-bceeba555675n%40googlegroups.com.

[王康文]

We have included a video to demonstrate the problem.

https://p.udn.com.tw/upf/static/common/kangw3n/Recording-cls-stars.mp4 

[王康文]

Dear Michal,

Thank you for your feedback. We will definitely explore the intrinsic size property, as most of our content (articles) has dynamic width and height.

Please allow me to break down each step to reproduce the issue we have observed:

1. Field Score: Our field data score was approximately 0.9 starting from mid-April, which coincides with the time we began rolling out content-visibility.
2. Implementation of content-visibility: Elements that are offscreen, specifically those elements after the article paragraphs.
3. Measurement Tool: Chrome Extension: Core Web Vitals.
4. Page for Observation: All article pages, e.g., https://stars.udn.com/star/story/10088/7970442

We have temporarily unset all content-visibility properties to monitor the change in our field data. This may be the reason why you are unable to reproduce the issue.
We alsoaware that sidebar ads may cause some shifting, but they usually do not contribute significantly to poor metric scores, likely around 0.05.

Here's how we managed to reproduce the mean score of approximately 0.9 with the current state of the site:

1. Open the site and wait for it to finish loading.
2. Enable the Chrome extension: Core Web Vitals. This will display an overlay with all Web Vitals metrics at the bottom-left side.
3. Open the developer tools and search for the CSS property: `* {content-visibility: unset !important;}`.
4. Toggle the on/off state, and the value changes drastically, definitively meeting the mean score we receive on our site's field data.

As we are unsure how the CLS (Cumulative Layout Shift) metric is precisely calculated or when the data is sent to Google, the above represents our observations and monitoring efforts. It might be caused by a faulty implementation on our part, which we will continue to monitor.

We have included a video to demonstrate the problem.

Thank you for your assistance.

Best regards,
kangwen