Cumulative Layout Shift (CLS) metric impacted by use of content-visibility property?

Question

Pages on our site have always had near-zero CLS. This makes sense, as they are server-rendered HTML page with a simple static layout.

Recently we added use of content-visibility: auto per the below (added only to below-the-fold sections):

https://web.dev/content-visibility/

section {
  content-visibility: auto;
  contain-intrinsic-size: 1000px;
}

This has no visible impact in the browser, but yields the expected significant benefits to paint/render metrics according to dev tools "Performance" tab, chrome lighthouse measurements, and repeated runs on webpagetest.org

However, we noticed cumulative layout shift (CLS) jumped drastically for 0.006 to 1.000+ in the lab data section on google pagespeed insights:

https://www.godaddy.com

https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwww.godaddy.com

Anyone else observe this? Potentially a bug in how lighthouses measures CLS?

Answer 1

Likely answering my own question - know bug with Chromium that has been fixed, would guess it's still present in other browsers and whatever powers google pagespeed insights:

Bug fix for content-visibility: auto When the content-visibility: auto feature was shipped in Chrome 85, a CLS-impacting flaw was present: changes between the skipped and not-skipped state of a content-visibility: auto subtree caused an observed layout shift in the content;visibility: auto element as it resized.

In Chrome 88, the CLS issue was fixed. Going forward, there should be no CLS penalty for such elements. (Note that there still may be a layout shift for onscreen elements adjacent to (but not descendants of) the content-visibility: auto element.

https://chromium.googlesource.com/chromium/src/+/master/docs/speed/metrics_changelog/2020_11_cls.md