Detailed explanation
Prefer animating transform and opacity because they can often update an element’s visual appearance without repeating layout or paint on every frame. By contrast, animating geometric properties such as top, left, width, and height generally requires layout work, potentially followed by paint. This matters because animation competes with JavaScript, input handling, and other rendering tasks. At 60 Hz, the browser has roughly 16.7 milliseconds to produce each frame; exceeding that budget can cause visible stuttering.
The browser’s rendering pipeline broadly involves calculating styles, computing layout, painting drawing instructions, rasterising pixels, and compositing layers onto the screen. Layout determines element sizes and positions, while painting and rasterisation produce their visual content. Changing width can affect text wrapping and neighbouring elements, increasing the amount of work needed. Changing left on a positioned element also updates layout geometry, although the affected area depends on positioning and containment. These properties do not necessarily force a full-document layout, but they commonly add work to each animation frame.
A transform changes how an element is displayed without changing its normal-flow layout footprint. For example, translateX(200px) visually moves a box while surrounding content keeps its original arrangement. Opacity changes how its rendered content is blended. When suitable content is available in composited layers, the browser can reuse rasterised pixels and update transformations or blending through the compositor, often with GPU acceleration. Eligible CSS transitions or animations can therefore advance without main-thread layout and paint on every frame. However, compositor execution is not guaranteed: initial painting, layer promotion, rasterisation, and browser-specific eligibility still matter.
In an interview, explain this as avoiding rendering work, not as a blanket promise of GPU-driven 60 fps. Use transform for visual movement and opacity for fading, but use actual layout changes when surrounding content must resize or reflow. Scaling is not equivalent to changing width: text and borders scale too. Verify results with browser performance tools, checking layout, paint, and dropped frames. Apply will-change selectively because additional composited layers consume memory and can themselves hurt performance.
Key points to remember
- Transform and opacity can run as compositor-only animations when eligible.
- Top, left, width, and height generally require layout updates when their animated values affect geometry.
- Compositing can reuse existing pixels instead of repainting content each frame.
- Transforms change visual placement, not the element’s normal-flow layout footprint.
- Profile actual rendering behaviour; neither GPU acceleration nor smooth frame rates are guaranteed.
Common mistakes candidates make
- Claiming transform and opacity always run entirely on the GPU and never require initial paint.
- Assuming every geometric change recalculates the entire document rather than an affected layout scope.
- Adding will-change or translateZ(0) everywhere without considering layer memory and compositing costs.
Likely follow-up questions
Should I always replace width animations with scaleX()?
No: scaleX() stretches the rendered content, including text and borders, without changing the space reserved in layout. Animate width when neighbouring content genuinely needs to move or reflow, and measure the cost.
What does will-change: transform do?
It hints that a transform will change, allowing the browser to prepare optimisations such as layer promotion. It does not guarantee compositor execution, and temporary hints should be removed when no longer needed.
Does updating transform with requestAnimationFrame avoid the main thread?
No: the JavaScript callback still runs on the main thread, even if the resulting transform avoids layout and paint. An eligible CSS or Web Animations API animation can advance on the compositor independently of main-thread JavaScript.
Interview tip: Explain the rendering pipeline first, compare left with translateX, and finish with the eligibility caveat and a profiling check.