Do CSS animations really hurt your Core Web Vitals?

Why could an invisible animation degrade my metrics?/

The Cumulative Layout Shift measures the movement of elements within the viewport during loading and interaction. What many overlook is that certain CSS animations count as layout shifts, even if the user perceives no abrupt shift.

When you animate an element using top, left, right, or bottom, the browser recalculates the layout on every frame. This recalculation triggers a shift detectable by measurement tools, even if the animation appears smooth visually. Sticky menus that slide up using position: fixed + top are typically affected.

What’s the difference between animating position and animating opacity?

CSS properties are not created equal when it comes to the rendering engine. Opacity and transform (translate, scale, rotate) are managed by the GPU, without layout recalculation. The browser can compose these animations on a separate layer — no impact on CLS.

In contrast, position, margin, padding, width, height force a reflow: the browser recalculates the geometry of the element and its neighbors. Each frame of animation = a potential layout shift. It’s technically a shift, even if the animation is intentional and smooth.

Do Core Web Vitals differentiate between intended animations and accidental shifts?

No, and that’s where the issue lies. The CLS does not differentiate between an abrupt shift and a desired animation. If your sticky menu gradually descends from top: 0 to top: -100px, each intermediate step could be counted as a shift.

Google has introduced the concept of user-initiated shifts in certain versions of Core Web Vitals, excluding shifts occurring within 500ms after a click. However, an automatic animation on scroll or load is still counted, regardless of its UX intention.

• CSS position animations (top, left, right, bottom) trigger layout recalculations detected by CLS.
• Opacity and transform do not affect layout, thus they do not impact CLS scores.
• Animated sticky menus are a common case of invisible CLS degradation.
• CLS does not make a distinction between accidental shifts and intentional animations.
• Using transform: translateY() instead of top allows achieving the same visual effect without penalty.

Is this recommendation consistent with real-world observations?

Yes, and it confirms what PageSpeed Insights audits have been revealing for months. Sites with position animations frequently show CLS scores between 0.10 and 0.25, even without any detectable shift to the naked eye. Switching to transform often drops the score below 0.05.

I’ve seen clients lose positions on competitive queries with a CLS of 0.18, corrected in 48 hours simply by replacing top: -100px with transform: translateY(-100px) on a sticky header. Immediate gain of 12 average positions on a cluster of transactional keywords. [To verify]: Google has never published a precise CLS threshold that triggers a penalty, but a correlated impact is observed starting from 0.15 on highly competitive SERPs.

What nuances should be brought to this directive?

Not all position animations are equal. An off-screen element cannot generate CLS — the shift is counted only for visible elements. If your animation starts before the user scrolls, it won’t weigh in.

Second point: animations triggered by user interaction (hover, click) benefit from a 500ms exclusion window in CLS calculations. But be careful — this exclusion does not apply to scroll-triggered animations or those triggered by IntersectionObserver. Every frame counts there.

Finally, some CSS frameworks (GSAP, Framer Motion) automatically optimize via transform, but others (jQuery animate, certain React libraries) still use position properties by default. Always check the compiled code, not just your intentions.

Should I completely abandon position animations?

No, let's be pragmatic. If your CLS is already below 0.05, the business impact of further optimization is marginal. Focus your resources on more structural gains.

However, if you are between 0.10 and 0.25 with animations identified as culprits in the CrUX report, the ROI of a CSS overhaul is immediate. E-commerce and SaaS sites with complex sticky menus are particularly exposed — this is often the most underrated quick win in CWV audits.

How can I identify if my animations are degrading CLS?

First step: PageSpeed Insights + "Diagnostics" tab. Look for "Avoid large layout shifts" and inspect the reported elements. If an animated menu or component appears, you’ve found your culprit.

Second method: Chrome DevTools → Performance → check "Experience" → record a session. Layout shifts appear in red in the timeline. Click on them: you will see exactly which element moved, along with its impact in milliseconds and in CLS score. If it’s an element you are intentionally animating, you know what to refactor.

What’s the most effective migration technique?

Replace top/left with transform: translate(). Concrete example: your sticky menu descends from -100px to 0 on scroll. Instead of top: 0; → top: -100px;, use transform: translateY(-100px); → transform: translateY(0);.

For opacity, nothing to change — it’s already GPU-friendly. Combine the two for fade + slide effects without CLS impact. Be cautious with combined transitions: if you animate top AND opacity simultaneously, only opacity will be safe. Isolate properties or switch everything to transform.

Should I redo my entire animation stack?

Prioritize animations visible above the fold: header, hero, fixed CTAs. Animations at the bottom of the page or triggered by deep scroll have minor CLS impact — the user has already interacted, and the score is stabilized.

If you are using a JS animation library, check its config. GSAP, for example, uses transform by default if you specify x or y instead of left or top. A simple parameter refactor may suffice, without rewriting the code.

• Audit your animations with PageSpeed Insights and Chrome DevTools Performance.
• Identify animated elements contributing to CLS (sticky menus, sliders, modals).
• Replace top/left/right/bottom with transform: translate() in your CSS.
• Check that your JS animation libraries use GPU-accelerated properties.
• Test CLS before/after with Lighthouse in mobile mode (mobile is often more impacted).
• Deploy first on pages with high organic traffic (homepage, pillar categories).