Closed simonferndriger closed 7 months ago
This should be raised on the Chrome bug tracker as it is based on how Chrome implements CLS rather than how this extension reports CLS.
However I would say this is your issue (emphasis mine):
Have an overlay sliding up using keyframes to animate the top property from 100vh to 0
As noted in the CLS documentation:
To move elements around, avoid changing the top, right, bottom, or left properties and use transform: translate() instead.
The effect should be the same, but with considerable less work for the browser since transform
animations can happen on the compositor layer. There have been some discussions as to whether this should count as CLS since an almost identifical effect for the user is possible with transform
in cases like this, but currently using top
does count towards CLS as it's not always easy to see when the effect will be the same and, as I say, that is more performant anyway.
OK, thanks for the hint regarding transform
!
Describe the bug The Web Vitals Extension detects a (technical) CLS which is not visible for moving elements that have opacity of
0
.To Reproduce Have an overlay sliding up using keyframes to animate the
top
property from100vh
to0
. Within that overlay have a (clickable) element that fades in with a delay usingopacity
.Expected behavior Since the clickable ad only starts getting visible (
opacity
> 0) after the sliding up animation from the overlay (background) is complete, there is no visual CLS, so the CLS value should be0
.Version:
Additional context, screenshots, screencasts Unfortunately, I had to change the behaviour in order to avoid getting a bad CLS value for the production site. But I added a recording as a video, hope it helps.
https://github.com/GoogleChrome/web-vitals-extension/assets/1435963/8a86a36d-795b-4a66-be68-2aeba731eaab