3

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?

Mike Robinson
  • 41
  • 4
  • Without something to test against this is a "how long is a piece of string question", but my guess is that because Page Speed Insights scrolls to the bottom of the page during the test faster than any human could your intrinsic sizes are no where near their actual size and it causes a layout shift as it quickly tries to render everything. However as with everything **how** you implemented this is very important, if you chunked everything on the page into one box then yes, it will certainly cause more issues than it solves. Do you have a page to test against to give some better answers? – GrahamTheDev Feb 11 '21 at 21:35
  • Thanks, @GrahamRitchie - appreciate the insight. Edited to include link. Chunks should be logical - each of the page's self-contained, below-the-fold sections. Think the team found the smoking gun, I added an answer which points to known CLS issues in Chromium that are incrementally being fixed. – Mike Robinson Feb 12 '21 at 01:01
  • Interesting but if I turn layout shift regions tracking on in Developer tools that page exhibits strange behaviour if you remove "scrolling: smooth" from the `` element. This may be related to the content visibility as the scroll bar jumps in a way that make me think content above the current position was removed. This behaviour is masked with `scroll: smooth` but the layout shift region still fires (for the whole page, hence CLS of 1) – GrahamTheDev Feb 12 '21 at 02:13
  • Some scroll bar "jumpiness" is expected since `content-visibility: auto` applies size containment and off-screen elements' height is only approximated (we set `contain-intrinsic-size` based on average size of our sections to minimize this). I see the supposedly shifted regions in devtools, but there is no actual visible shift, and lighthouse in the browser also indicates CLS of zero. The scroll bar behavior might require we revert this anyway, but I'm questioning the usefulness of this property based on the scroll bar behavior and problems with CLS metrics... – Mike Robinson Feb 12 '21 at 14:31
  • Sorry I should have clarified, the scroll bar should jump as you scroll down the page and as element are rendered (making the page either longer or shorter than the size you said a section would be), but what isn't meant to happen is that elements **above** where you currently are in the page layout again and change sizes. Scroll slowly you will see what I mean, this is what is causing the CLS (to be fair I am viewing on a 4k monitor so maybe it is a resources optimisation - 2 secs let me try and 1920px) – GrahamTheDev Feb 12 '21 at 15:05
  • Even worse (which makes sense as I see less of the screen) - it appears to be removing elements above and reverting their size, that is not how it is meant to work, once loaded those items should have their containing box size calculated and remembered by the browser, even if the actual rendering is undone. Remove it for now, too experimental, hopefully they will fix for the future. (unless of course you can set the `contain-intrinsic-size` to the **exact** size it needs to be somehow, it would work fine then.) – GrahamTheDev Feb 12 '21 at 15:08
  • I have a workaround in my head. Leave it as it is in the CSS. Then use `intersectionObserver` and when the section enters the viewport measure it's actual height and set the `contain-intrinsic-size` to exactly the size it needs to be. This should stop jumping about on scroll up and the jumping scrollbar is acceptable enough when scrolling down for the first time. – GrahamTheDev Feb 12 '21 at 15:12
  • Thanks again, @GrahamRitchie. First - lighthouse CLS seems fixed, with no changes to the page... luck, maybe. Second, your `intersectionObserver` workaround for scroll bar shift is genius - tried it, and it effectively addressed the issue. In the end, we opted instead to limit usage of these new properties to mobile-only breakpoints while browsers work through issues... scroll bar shift isn't nearly as user-impacting and those devices are the ones that benefit from layout/paint savings anyway. – Mike Robinson Feb 14 '21 at 20:47

1 Answers1

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

Mike Robinson
  • 41
  • 4
  • Yes, this bug has been fixed, but PageSpeed Insights (as well as the Chrome UX Report API) shows data for a rolling 28-day period, so it'll take about a month for data captured by those tools to no longer have this bug. – Philip Walton Feb 22 '21 at 17:27