Architecture Walkthrough

The Stages

Turning a DOM tree and a stylesheet into pixels runs through a sequence where each stage consumes the previous one's output.

Recalculate style. Match selectors against elements and compute the final value of every property for every element, producing the computed style for each node. Cost scales with the number of elements times the complexity of matching. Usually small, but with tens of thousands of nodes or very large stylesheets it becomes measurable.

Layout, also called reflow. Compute the geometry of every box: size and position. Output is the box tree with concrete coordinates. This is the most expensive stage, because geometry is interdependent: changing one element's width can change where its siblings sit, how tall its ancestors are, and where anything positioned relative to them lands. The cost therefore scales with the surrounding document, not with the element being changed.

Paint. Fill in pixels: backgrounds, borders, text, shadows, images, producing paint records or rasterised bitmaps. Cost is roughly proportional to the area repainted and to the complexity of what is drawn. Text shaping, gradients, box-shadow blur, and border-radius clipping are all more expensive per pixel than a flat fill.

Composite. Assemble the painted layers in the correct order, applying transforms, opacity, and filters, then hand the result to the display. This is comparatively cheap, because it is mostly the GPU positioning and blending bitmaps that already exist.

Which Thread Does What

Recalculate style, layout, and paint run on the main thread, the same thread that runs JavaScript. Compositing runs on a separate compositor thread, usually with GPU assistance, and can also handle scrolling.

That split matters more than the per-frame cost. An animation that only needs compositing can be handed entirely to the compositor thread, where it continues at full frame rate even while the main thread is blocked by a long task. An animation that needs layout or paint competes with JavaScript for the main thread, so it stutters at precisely the moments the page is busiest, which is usually when the user is most likely to notice.

Where Each Property Enters

A property's animation cost is determined by the earliest stage it invalidates, because everything from that stage onward must rerun.

Layout → Paint → Composite. Anything that changes geometry: width, height, top, left, right, bottom, margin, padding, border-width, font-size, font-weight, line-height, flex-basis, grid-template-columns, display. Every animated frame pays for all three stages, and the layout portion scales with the document.

Paint → Composite. Properties that change appearance without geometry: color, background-color, background-image, border-color, border-radius, box-shadow, outline, visibility, text-decoration. No layout, but the repaint cost scales with area, and box-shadow with a large blur radius is among the more expensive things a browser rasterises.

Composite only. transform, opacity, and usually filter. These change how an existing layer is positioned, scaled, or blended without altering geometry or painted content, so they can run on the compositor thread.

Deriving this rather than memorising it is the point: if a property changes the size or position of a box, layout is unavoidable; if it changes what is drawn inside the box, paint is unavoidable; if it changes neither, compositing suffices.

Compositing Is Not Free

The common overcorrection is to treat compositor-only animation as costless.

Compositing requires the element to have its own layer, which means its own bitmap in GPU memory. A full-screen element at a 3x device pixel ratio is a large allocation, and promoting many elements or very large ones trades main-thread work for memory pressure. On low-end mobile hardware, that trade can be worse than the layout it avoided.

will-change promotes in advance, avoiding a hitch at the animation's start, but it promotes for as long as the declaration applies. It belongs on an is-animating class rather than permanently in a component's base styles. The older translateZ(0) and backface-visibility: hidden tricks do the same thing and additionally create a stacking context, which is a frequent cause of unrelated z-index bugs.

Worth separating two ideas that are often conflated: a stacking context is a spec concept about paint order, while a compositing layer is a browser implementation detail about GPU bitmaps. Some things create one, some the other, some both, and neither implies the other.

Reducing Work Structurally

Beyond choosing cheaper properties, the pipeline can be given less to do.

contain: layout promises that an element's internal layout cannot affect anything outside it, so a layout pass inside it does not walk the rest of the document. contain: paint promises nothing paints outside its bounds. contain: strict combines them with size containment.

content-visibility: auto skips style, layout, and paint entirely for off-screen subtrees, which is the largest single win available for long pages.

Reducing DOM size and selector complexity lowers the style recalculation cost, which matters at scale even though it rarely dominates.

Measuring

The Performance panel colour-codes the stages: purple for layout, green for paint, and it flags forced synchronous layouts with a warning. The Rendering panel's paint flashing highlights repainted regions, which makes an unexpectedly large repaint obvious. The Layers panel shows which elements have been promoted and the memory each layer consumes.

Together those three answer the practical questions definitively: is this animation compositor-only, how much area is repainting, and how much GPU memory did promotion cost. That is better than reasoning from a property list, because the list cannot tell you the area or the memory.

Key Code Explained

/* LAYOUT -> PAINT -> COMPOSITE, and layout scales with the DOCUMENT */
.grow-slow {
  width: 100px;
  transition: width 300ms ease; /* reflows siblings and ancestors each frame */
}
.grow-slow:hover {
  width: 200px;
}

/* COMPOSITE ONLY — handed to the compositor thread */
.grow-fast {
  transform: scale(1);
  transition: transform 300ms ease;
}
.grow-fast:hover {
  transform: scale(2); /* no layout, no repaint of content */
}

/* PAINT -> COMPOSITE: no layout, but cost scales with AREA */
.tint {
  transition: background-color 200ms ease;
}
.shadow-heavy {
  transition: box-shadow 200ms ease; /* large blur radii are expensive to rasterise */
}
/* Cheaper alternative: animate the opacity of a pre-painted shadow layer */
.shadow-cheap {
  position: relative;
}
.shadow-cheap::after {
  content: '';
  position: absolute;
  inset: 0;
  box-shadow: 0 8px 24px rgb(0 0 0 / 0.2);
  opacity: 0;
  transition: opacity 200ms ease; /* composite only */
}
.shadow-cheap:hover::after {
  opacity: 1;
}

/* The compositor-friendly pair, used together */
.toast {
  opacity: 0;
  transform: translateY(8px);
  transition: opacity 200ms ease, transform 200ms ease;
}
.toast.is-visible {
  opacity: 1;
  transform: translateY(0);
}

/* will-change: on an is-animating class, not in the base styles */
.drawer.is-animating {
  will-change: transform;
}

/* Give the pipeline LESS TO DO, not just cheaper properties */
.widget {
  contain: layout; /* a layout pass inside cannot walk the whole document */
}
.card {
  contain: paint;  /* nothing paints outside its bounds */
}
.long-list > .row {
  content-visibility: auto;        /* skip style, layout, and paint off-screen */
  contain-intrinsic-size: 0 80px; /* keeps the scrollbar stable */
}

/* transition: all is a pipeline hazard: it will animate layout properties */
.avoid {
  transition: all 200ms ease;
}

The .grow-slow versus .grow-fast pair is the derivation in practice. Both make an element twice as large over 300ms. width changes geometry so layout is unavoidable, and because layout is interdependent the cost involves the surrounding document rather than just the card. scale changes neither geometry nor painted content, so compositing suffices and the work leaves the main thread entirely.

The .shadow-cheap pattern is the more interesting one, because it shows how a paint-stage animation can be converted into a composite-stage one. Instead of animating box-shadow and re-rasterising the blur every frame, the shadow is painted once on a pseudo-element and its opacity is animated. The visual result is nearly identical and the per-frame work drops from paint to composite.

Tradeoffs

What Interviewers Actually Check

• Whether you can name all stages in order, including recalculate style
• Whether you place properties into stages by reasoning rather than recall
• Whether you know layout cost is interdependent and paint cost is area-proportional
• Whether you identify the main-thread versus compositor-thread split as the decisive factor
• Whether you acknowledge that layer promotion has a memory cost

Follow-Up Questions

1. What is the difference between a stacking context and a compositing layer, and which properties create each?
2. How does the FLIP technique animate a genuine layout change using only compositor properties?
3. What exactly does contain: strict promise, and when would it break a layout?
4. Why can content-visibility: auto cause scrollbar instability, and what does contain-intrinsic-size do about it?
5. How would you use the Performance, Rendering, and Layers panels together to characterise an animation's cost?

Common Candidate Mistakes

• Reciting the "animate only transform and opacity" rule without being able to derive it from the pipeline, which leaves you unable to reason about a property not on the list
• Conflating stacking contexts with compositing layers, when one is a spec-level paint-order concept and the other a GPU memory implementation detail
• Assuming paint cost is independent of area, when repaint work scales with the region and with the complexity of what is drawn
• Overlooking that recalculate style has its own cost, which becomes measurable with very large DOMs or very large stylesheets
• Treating GPU-accelerated compositing as free, when each promoted layer allocates a bitmap and heavy promotion trades main-thread work for memory pressure

Interview Readiness Checklist

Before you leave this question, make sure you can answer:

• Can you name all pipeline stages in order and say what each produces?
• Can you place an arbitrary property into the stage it enters at, by reasoning?
• Can you explain why layout is interdependent and why paint scales with area?
• Can you say which stages run on which thread, and why that split matters most?
• Can you derive from first principles why transform and opacity are the cheap pair?

Summary

Rendering runs through recalculate style, layout, paint, and composite, each consuming the previous stage's output. Style matching produces computed values per element. Layout produces box geometry and is the most expensive stage because geometry is interdependent, so one element's change can ripple through siblings, ancestors, and anything positioned relative to them. Paint produces pixels and costs roughly in proportion to the repainted area and the complexity of what is drawn. Composite assembles existing layers with transforms, opacity, and filters, and is comparatively cheap.

A property's animation cost follows from the earliest stage it invalidates, since everything after must rerun. Geometry properties such as width, height, top, and font-size enter at layout and pay for all three stages every frame. Appearance properties such as background-color, border-radius, and box-shadow skip layout but pay area-proportional paint. transform and opacity change neither geometry nor painted content and need only compositing, which is why they are the cheap pair, a conclusion you can derive rather than memorise.

The decisive factor is the thread split. Style, layout, and paint run on the main thread alongside JavaScript, while compositing runs on the compositor thread with GPU assistance, so a compositor-only animation keeps its frame rate even while the main thread is blocked. Compositing is not free, though: each promoted element allocates a GPU bitmap, so will-change belongs on an is-animating class rather than permanently in base styles. Beyond choosing cheaper properties, contain: layout and contain: paint shrink the scope of a pass and content-visibility: auto skips off-screen work entirely, and the Performance, Rendering, and Layers panels are what turn all of this from reasoning into measurement.