3

We are a 3rd-party vendor that adds components / UI elements to our clients' websites. We sometimes hide/change the size of this container in run-time, based on contextual parameters or as part of A/B testing.

It is impossible for the website owner to know the final size of the element before we have all the contextual data, so the height cannot be set on the server-side.

To minimize the effect on CLS, the website owner can set an initial height for the container, but this has two issues:

  1. It does not completely eliminate CLS, only reduces it slightly
  2. It creates a bad UX where the page loads up with a white space which then disappears / changes height

What is the recommended approach for eliminating the CLS impact of such an element?

Tudmotu
  • 845
  • 8
  • 11

1 Answers1

1

We sometimes hide/change the size of this container in run-time, based on contextual parameters or as part of A/B testing.

Any time you change the size of content at runtime, you risk shifting other content on the page around, and that can negatively affect the use experience. Before you spend a lot of time trying to "fix" CLS for your use case, you might want to consider whether your use case if the right experience for users.

If you cannot change your system and just want to minimize its impact on CLS, here are some options:

  • Collapse the area only after user input (perhaps ask users to close the container, or, wait for some other expected reason for page re-layout).
  • Only collapse if all affected content is outside of the viewport. It sounds like you already do this for below-the-fold? For above-the-fold content, you may be able to simultaneously remove content and adjust the scroll position by the exact same amount.

And, perhaps some broader alternatives are:

  • Don't collapse the area, but replace it with some default content that cannot fail.
  • Likely not an option, but maybe there are ways to delay showing content until you know if the conditional content will be needed? This depends on how late loading your content is and will have negative tradeoffs with loading performance if you cannot answer that success test quickly...
Philip Walton
  • 29,693
  • 16
  • 60
  • 84
  • Thank you! A couple of questions: 1. What are "other expected reasons for page re-layout"? 2. You mention "adjusting the scroll position" - if we do that, does it not count towards CLS? e.g If I increase the height of the container by 20px, and increase the scroll position by 20px, does it eliminate the CLS? – Tudmotu Mar 22 '21 at 16:52
  • "other expected reasons for page re-layout" include things like the window resizing or the user changing the page orientation on mobile. As for scroll offset compensation: shifts that occur by the same amount as as a scroll offset change (within the same frame) are not considered layout shifts because, from the user perspective, they do not see a shift. – Philip Walton Mar 22 '21 at 16:59
  • By the way, you can always test something to see if it's causing a layout shift. I'd recommend reading https://web.dev/debugging-layout-shifts/ for ideas on how to debug CLS. – Philip Walton Mar 22 '21 at 17:00
  • Yes, we know this post :) We will test the "scroll compensation" option. I am a bit worried what would happen if every 3rd-party vendor will use this technique - will we all changes the scroll position all the time? Do you think this is something that can be solved with some standard API that will "queue" changes and automatically adjust the scroll position? – Tudmotu Mar 22 '21 at 18:19
  • The change needs to happen in the same frame, so as long as you measure the size once and then make the change to size and scroll offset at the same time (within the same frame), I don't think there's any risk of multiple source causing it to get out of sync. – Philip Walton Mar 22 '21 at 20:49