Layout Shift on Splash Screens

51 views
Skip to first unread message

Kevin Farrugia

unread,
Jan 20, 2021, 4:42:34 AM1/20/21
to web-vitals-feedback
Hi,

I would like to find out whether a layout shift hidden behind a splash screen should contribute to CLS. 

By definition, layout shifts only contribute to CLS if they are visible to the user, so layout shifts beneath the fold do not contribute. However, layout shifts above the fold hidden beneath another element (such as a fullscreen animation) are not visible, and therefore should not contribute to CLS.

I have a simple demo which includes two layout shifts, the first when the image loads and the second when the ad above the content loads. If there is no splash screen, these would be optimised using fixed width/height placeholders, however if there is a splash screen is this still required. At the moment Chrome is still reporting a layout shift and the CLS score is the same (with and without splash screen).


Note that in the demo, the splash screen disappears after a fixed time and is not waiting on the content to be loaded. By setting a high timeout value (for demo purposes) I can make sure that the splash screen disappears after all layout shifts have occurred.


Philip Walton

unread,
Jan 26, 2021, 5:46:50 PM1/26/21
to Kevin Farrugia, web-vitals-feedback
Hey Kevin, thanks for the feedback (it actually sparked quite an interesting discussion internally)!

The short answer is you're correct that the Layout Instability API currently does not ignore elements that shifted but were not visible due to another element being positioned in front of them.

The API does *does* currently ignore elements that are not visible due to setting `display: none`, `visibility: hidden`, or `opacity: 0`. And I'd recommend you use one of those properties to avoid layout shifts in cases where you need to run layout on some elements before you make them visible to the user.

In terms of future changes to the API, we're going to look into whether it would be possible (without degrading performance) to determine that an element is not visible to the user due to stacking order, but it's not clear whether or not that will be possible.

If we are able to make that change, we'll announce it on the metric CHANGELOG.



--
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/ebec002f-638c-48c0-99b0-bd5050dc07f7n%40googlegroups.com.

Kevin Farrugia

unread,
Jan 27, 2021, 4:40:39 AM1/27/21
to Philip Walton, web-vitals-feedback
Hi Philip,

Thank you for the response & explanation. To summarise, until/if there are changes to the Layout Instability API, using a splash screen isn't a solution to minimise layout shift, but the layout shifts beneath the splash screen (or any other overlapping element) need to be handled as if there wasn't the overlapping element.

Also, while I can confirm that setting display: none or content: visibility work as a good workaround as there is no layout shift (toggling `display: none` has its own issues and I wouldn't recommend it as it increases Layout time), setting opacity: 0 seems to still registers a layout shift from what I can see.

Kevin Farrugia

unread,
Jan 27, 2021, 4:44:25 AM1/27/21
to Philip Walton, web-vitals-feedback
Ah, I see that the `opacity: 0` layout shift will be changed in Chrome 89. 👍

Philip Walton

unread,
Jan 27, 2021, 2:03:49 PM1/27/21
to Kevin Farrugia, web-vitals-feedback
Yep, that's correct :)
Reply all
Reply to author
Forward
0 new messages