Cumulative Layout Shift (CLS) is an important aspect of Google Core Web Vitals. It factors into your ranking and user experience, so removing CLS is incredibly important for website owners.

Read: What exactly is Cumulative Layout Shift?

A layout shift occurs when a slow-loading element is added to an already-rendered page, causing content and layout to move, or shift. You may be reading a paragraph, and when the slow-loading element (typically a massive image or advertisement) finally shows up, it pushes the content around, and you loose your spot.

A great example of why CLS is bad.

In some cases, specifically with a slow loading advertisement, you may inadvertently click on it, making for a horrible UX.

That is known as an individual layout shift, to calculate Cumulative Layout Shift, Google adds up all individual instances of Layout Shift.

According to the KB article, "CLS is a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifespan of a page."

Google wants to minimize this, so they factor CLS into the ranking of your site.

With the popularity of Javascript Animation Libraries exploding, many are wondering: Do animations impact CLS?

The good news is that animated elements typically don't impact CLS. While they're looking for unexpected movement over the lifespan of the page (ie when a visitor is on an individual page), EXPECTED shifts are good to go.

So, if a user clicks a button that toggles content, shifting the page, that is fine.

When animating content, do it gradually and naturally. Changing things that have no impact on the position of content within a page (such as color, background, ect) have no impact whatsoever.

Where you could get in trouble (and Google mentions this), is when you sporadically modify the height and width, or the positioning by messing with top, bottom, left, or right. Instead, opt for transforming the scale, or translating the element, as these animations will not push other content around on the site.

The reason behind using the transform property is shown with the example above. While the shape or position of the square changes, the initial placement does not (you're altering the coordinate space, not the surrounding VFM Box). Any "dimensions" that have been changed will simply overlap existing content, and will not push it out of the way.

Furthermore, shown with the yellow dashed outline, the initial placement (Visual Formatting Model box) remains intact in terms of shape, size and dimensions. This means that content won't move into that position, and there will be no layout shift.

Google will actually just ignore anything animating transforms when it comes to CSS. Because of that, this is the safest animation type to do when considering CLS and UX.

Even with that said, as long as the user themselves is initializing the animation, there should be no negative impact. For a visual example, check out the video below (timestamp 17:51). This is using Motion.Page, a visual animation builder for WordPress (our review) to apply a GSAP animation to a div. In this situation I am manipulating height and width, going from 33vw and 370px height to 100vw and 100vh. This not only changes the size of the content within, but the size of the VFM box, which pushes other divs, content and containers out of the way.

This change pushes content down, and the images beside the core element off the page: by definition, a layout shift! But testing with Google Lighthouse in Chrome DevTools shows that this has no impact on CLS!

That's because it doesn't cause content to unexpectedly shift around. It's slow and gradual. Additionally, for these types of audits, it occurs below the fold, after the DOM and page has loaded completely.

Of course, I wouldn't add something like this in the middle of a blog post - even if Google testing tools don't pick this up, it's a terrible UX when an animation takes over the entire website.

A final thing when it comes to animating the height and width of an element. If you wrap it in a div/container that has dimensions that are the same as the dimensions that the animation results in (ie a container for the animated element to fill into), content will not be pushed as space is already there.

This is a similar concept to adding height and width to images and then lazy loading them. The height and width will render a container, and when the image loads, it won't push content out of the way.

What it boils down to is this:

• Test all animations for CLS. Use Lighthouse or PageSpeed Insights
• When possible, don't animate width, height, and positioning, instead use translate
• When possible, have a user toggle a "risky" animation that will move content on a page. This could be done by hovering or clicking a button.
• IF animating the real dimensions or positions of an element, you may want to have a space for it to move into, meaning that it won't cause a layout shift.
• If you have CLS, and you're following these tips, it's probably something else. The audit will tell you.

TLDR: you shouldn't really worry about CLS with GSAP or other JS animation libraries that impact CSS properties over a fixed period of time. Even if you are animating something that changes the position of content within a page, as long as the user initiates it, it's expected, and it's natural, it won't impact CLS or UX.