Browsers aim for 60 frames per second, meaning each frame should complete in roughly 16.7 milliseconds. To understand animation performance, it helps to know the rendering pipeline. After layout and paint, compositing is the final step where painted layers are combined into the screen image. Animations that only affect compositing — those using transform and opacity — can be handled by the GPU on the compositor thread without triggering layout or paint, so they animate smoothly even when the main thread is busy.
Animating properties that affect layout, such as width, height, top, left, or margin, forces the browser to recalculate layout on every frame, a phenomenon called "layout thrash" that severely hurts performance. Animating width versus transform: scaleX is a classic comparison: scaleX uses the GPU and does not trigger layout, while width triggers reflow every frame and is much slower. This is why animating transform and opacity is preferable to animating top/left, and why the typical frame rate of 60fps can drop sharply when layout-affecting properties are animated.
The will-change property hints to the browser that an element will be animated, often promoting it to its own compositor layer so the animation can run more smoothly. will-change: transform, opacity tells the browser to pre-allocate layers for those properties. However, will-change is not free: each layer consumes memory and GPU resources, and overusing it on many elements can hurt overall performance. It is best applied sparingly to elements that genuinely need the hint. Similarly, transition: all can cause performance issues because it animates every changing property, including unintended ones like filter or box-shadow that can be expensive.