Lesson 11 of 30
The same render pipeline that runs once at page load re-runs every time JS changes a style after the page is interactive — and which stages it re-runs depends entirely on which CSS property changed.
13 min read
Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.
Question 1 of 3
In the DevTools Performance panel, a frame during a `transform`-driven animation shows only a "Composite Layers" bar, with no Recalculate Style, Layout, or Paint entries. What does this indicate?
Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.
Sign up freeWhat interviewers actually ask about this, and what a strong answer has to cover.
A strong answer covers
Likely follow-ups
You already know the browser's pipeline: Style → Layout → Paint → Composite. The Frontend Practices track covers that sequence for the initial page load. This lesson is about the same pipeline running again — potentially dozens of times a second — every time JavaScript changes a DOM element's style after the page is already interactive: a class toggle, an inline style mutation, a CSS-in-JS update, a requestAnimationFrame loop driving an animation.
The critical fact most people memorize as a rule without knowing the mechanism: not every style change re-runs the whole pipeline. The browser is smart enough to figure out the minimum work a given change actually requires, and which CSS property you touched decides how much of the pipeline restarts:
width, height, top/left with position, font-size, margin, display) force the full path: Style → Layout → Paint → Composite. The browser doesn't know the new size/position of anything without recomputing layout, and that recomputed layout can cascade to surrounding elements too.background-color, box-shadow, color, border-color) skip Layout — geometry hasn't changed, so nothing needs repositioning — but still require Paint → Composite, because actual pixels changed.transform, opacity) can skip Style recalculation of geometry, Layout, and Paint entirely, going straight to Composite. If the element already has its own compositor layer, the GPU can just redraw that layer at a new position/opacity without the main thread recalculating anything about the page's visual content.That third path is the actual mechanism behind "animate transform/opacity, not top/left" — it isn't an arbitrary rule, it's a direct consequence of which pipeline stages each property does and doesn't require.
const box = document.querySelector(".box");
// Path 1 — forces Style → Layout → Paint → Composite (most expensive)
box.style.left = "200px";
// Path 2 — skips Layout, still needs Paint → Composite
box.style.backgroundColor = "crimson";
// Path 3 — skips Style, Layout, AND Paint — goes straight to Composite
box.style.transform = "translateX(200px)";
The same box, about to be changed three different ways after the page is already interactive.
All three lines move or visually change the exact same element on screen, and to a user watching casually they might look similar. The difference is entirely in how much work the browser does to get there. left requires knowing the new geometry before anything else can happen — Layout has to run, and because this element might affect siblings' positions too, that Layout pass can cascade well beyond just this one box. backgroundColor never changes geometry, so Layout is skippable, but the pixels themselves are different, so Paint has to redraw them. transform changes neither the element's layout geometry nor its painted pixel content — it just repositions an already-painted layer, which the compositor can do on its own, often on a separate thread from the one running your JavaScript.
width change in a busy loop is so much more expensive than it looks.transform/opacity change actually reaches the cheap path. If the element isn't on its own compositor layer, the browser may still fall back to a more expensive path the first time. Layer promotion (covered in the next lesson) is what guarantees the fast path is available when the change happens."Why is animating transform smoother than animating top/left?" is a near-guaranteed senior-frontend question, and tracing the answer through which specific pipeline stages each property requires — not just reciting "transform is GPU-accelerated" — is what separates a candidate who understands the mechanism from one repeating advice.