Non-Composited Animations

Why They Matter

• They cause visible stuttering. Non-composited animations trigger layout recalculations on every frame. When the browser cannot keep up, frames are dropped and the animation looks choppy. Users notice this immediately — it makes the whole site feel unpolished.
• They block the main thread. Layout and paint operations run on the same thread that handles user input and JavaScript. A heavy animation can make buttons unresponsive and scrolling jerky because the browser is too busy drawing frames.
• They hurt Core Web Vitals. Expensive layout recalculations during animations contribute to Cumulative Layout Shift and can delay Interaction to Next Paint. Smooth composited animations avoid these performance penalties entirely.
• They hit mobile devices hardest. Phones have less processing power and smaller batteries. Non-composited animations drain both — the CPU works harder, the device heats up, and battery life suffers. GPU-composited animations are far more efficient.

How to Fix Them

1. Animate only transform and opacity. These two properties are composited by the GPU and do not trigger layout or paint. Instead of animating left, use translateX(). Instead of animating width, use scaleX(). The visual result is often identical, but performance is dramatically better.
2. Use will-change sparingly. Adding will-change: transform to an element hints to the browser that it should promote the element to its own compositor layer in advance. Use it only on elements you actually plan to animate — overusing it wastes memory.
3. Replace margin and padding animations. Moving elements by animating margin or padding forces layout recalculation on every frame. Switch to transform: translate() for the same visual movement without the layout cost.
4. Avoid animating height and width. These properties trigger full layout recalculation because they change how surrounding elements are positioned. If you need a grow/shrink effect, animate transform: scale() instead.
5. Test animation performance on real devices. An animation that runs smoothly on your development machine may stutter on a mid-range phone. Use your browser's Performance tab to check frame rates and identify non-composited animations causing dropped frames.

Common Mistakes

• Animating layout-triggering properties without realizing it. Properties like top, left, width, height, margin, and padding all trigger layout. Many developers animate these by default without knowing the performance cost.
• Overusing will-change. Applying will-change to dozens of elements or using will-change: all consumes GPU memory and can actually make performance worse. Only promote elements that are actively being animated.
• Not testing on mobile. Desktop browsers handle non-composited animations much more gracefully than mobile browsers. If you only test on desktop, you will miss stuttering and jank that mobile users experience every time.
• Using JavaScript animation libraries for simple effects. CSS transitions and animations handle transform and opacity natively with GPU compositing. Adding a JavaScript library to animate these same properties adds overhead without benefit.