Why is animating transform preferred over top or margin-left?

WHAT THIS TESTS: This question probes whether you understand the browser rendering pipeline and how property choice directly impacts user-perceived performance. Interviewers want to see that you know frame rate is not accidental but determined by which rendering phases a property triggers. The MDN performance fundamentals note that responsiveness is the time between input and pixel change, and that smooth motion requires updating pixels at roughly 60 frames per second. Animating the wrong properties forces the browser to do more work between input and pixel change, violating those responsiveness and frame rate goals.

A GOOD ANSWER COVERS: First, name the three key rendering phases: layout, paint, and composite. Second, state that transform and opacity are compositor-only properties, meaning they skip layout and paint and run directly on the GPU during the composite phase. Third, explain that top, left, margin-left, width, and similar properties trigger layout recalculation, which is expensive because it cascades through the document tree and must happen before paint. Fourth, connect this back to frame rate: layout-heavy animations consume more time per frame, causing missed frames and jank, while compositor animations stay smooth even on lower-end devices. Fifth, mention that transform also avoids rounding errors and sub-pixel antialiasing issues that can make top or left animations look blurry.

COMMON WRONG ANSWERS: A red flag is claiming the difference is only syntax or browser quirks. Another is saying top is fine for small elements or that modern browsers are fast enough to optimize margin-left automatically. Some candidates mention will-change without explaining why it helps, which is the compositor promotion mechanism. Avoid suggesting that absolute positioning removes the layout cost, because changing top still forces the browser to recalculate the position of that element and potentially its siblings or parents.

LIKELY FOLLOW-UPS: An interviewer might ask which other properties are safe to animate, so know that opacity and filter are also compositor-friendly. They might ask how to animate layout properties smoothly if you must, in which case you should discuss FLIP techniques or using requestAnimationFrame to batch reads and writes. They could also ask about the impact on accessibility or reduced-motion preferences, which shows design systems maturity.

ONE CONCRETE EXAMPLE: Imagine a sidebar that slides in from off-canvas. Animating left from negative 300 pixels to zero triggers layout on every frame, recalculating geometry for the sidebar and potentially shifting content in the main area. The frame rate can drop to 30 frames per second or lower on mobile. Animating transform translateX instead moves a pre-composited layer, keeping the frame rate at 60 frames per second with no layout work. If you need to reserve space, you can animate transform and then snap layout at the end, or use a FLIP calculation to make the browser do one layout at the start and one at the finish.

Source: developer.mozilla.org