CLS being reported due to filter CSS transition about web-vitals HOT 3 CLOSED

This is a very interesting one! And I had to pull out some favours with some CSS colleagues to figure it out.

Apparently applying filter is one of the properties that creates a new stacking context so, as that's added and removed as you hover over it, that's causing a slight recalc in the CSS which technically causes a change in the pseudo elements position (even though there's no visible change to the user).

The easiest way to prevent this is to create that new stacking context in advance, by uncommenting one of the two properties below:

      .overlay-container {
        transition: filter 0.2s ease-in-out;
        /* filter: brightness(1); */
        /* will-change: filter; */

The first (filter: brightness(1);) sets the filter property even in unhovered state to the default of 1 so it has a filter value and knows therefore that it needs it's own stacking context for when you change this default later.

The second (will-change: filter;) explicitly tells the browser that it needs it's own stacking context as a filter is going to be changed later. It's probably the cleaner of these two options as doesn't require you to explicitly set a default value (that might interfere with other CSS you have).

Should Chrome count this as CSS when there is no user-visible change? No, it probably shouldn't. So feel free to raise a bug at crbug.com/new, however it's quite a minor one in this case (do let us know if you have a bigger example!) and it'll actually be ever so slightly more performant to do the solution above, so I imagine it won't be the biggest priority to look at this.

Oh and btw, on that note, Chrome-specific issues should be raised to crbug.com or to our web-vitals-feedback group, rather than here. This repo is specifically for the web-vitals.js library and this issue could have been repeated with a layout-shift performance observer even outside the library (though you may not have realised that!).

from web-vitals.

UPDATE: using the will-change property fixes the issue on our end as well 💯

Excellent! Great to hear.

from web-vitals.

UPDATE: using the will-change property fixes the issue on our end as well 💯

Thanks for looking into this and for the suggestions. I guess on our end, I still need to figure out why the numbers we're seeing are larger than the reproducible example I sent above but in the meantime, I'll apply your suggestion and move on.

Oh and btw, on that note, Chrome-specific issues should be raised to crbug.com rather than here, or to our web-vitals-feedback group. This repo is specifically for the web-vitals.js library and this issue could have been repeated with a layout-shift performance observer even outside the library (though you may not have realised that!).

That makes sense. I wasn't sure where the problem was, good to know for next time.

from web-vitals.