Browser Compositing

Compositing is the stage where a browser combines independently rendered visual layers to produce the final pixels shown on screen. Because some changes can be handled at the layer-compositing stage, the browser may avoid repainting affected page content.

A browser typically processes visual changes through stages such as style calculation, layout, paint, and compositing. Painting produces the visual contents of elements, while compositing determines how eligible layers are combined, positioned, transformed, and blended into the final frame.

A composited layer is rendered separately from other content so that the compositor can manipulate it independently. Common reasons for separate compositing include certain transforms, opacity animations, fixed-position behavior, video, and browser-specific layer-promotion decisions.

Compositing can improve animation performance because changing a layer's transform or opacity may be possible without repainting the layer's contents. However, creating additional layers is not automatically beneficial: layers consume graphics memory and can introduce overhead for rasterization, uploads, synchronization, and management.

For frontend performance work, distinguish compositing from painting. A change that reaches only the compositor can be relatively cheap, whereas a change requiring repainting may require new pixels to be generated before those pixels can be composited. Layout changes can be more expensive still because they may require geometry recalculation followed by painting and compositing.

CSS properties and browser heuristics influence whether content is composited separately. Developers should measure actual rendering behavior with browser performance tools rather than assuming that a property such as `transform` or `will-change` always creates a useful independent layer.

Key points

Interview questions

What is compositing in a browser rendering pipeline?

Compositing is the stage that combines separately rendered visual surfaces into the final frame. The compositor can apply operations such as positioning, transforms, opacity, and blending to those surfaces. This can let certain visual updates happen without repainting their contents. The exact set of composited elements is determined by the browser's rendering implementation and heuristics.

Why can animating `transform` be more efficient than animating layout properties?

A transform can often be applied to an already-painted surface by the compositor. That can avoid recalculating layout and repainting the affected content on every animation frame. In contrast, changing properties that affect layout can trigger geometry calculations and additional rendering work. The performance difference should still be verified with profiling because browser behavior and the surrounding page matter.

What does `will-change: transform` do, and when can it be harmful?

`will-change` tells the browser that an element is expected to change in a particular way, giving the rendering engine an opportunity to prepare for that change. For suitable elements, this can help make an animation smoother by enabling more favorable rendering treatment. It is not a guarantee that a separate layer will be created, nor is it free. Applying it broadly can increase memory usage and other rendering costs, so it should be used selectively and measured.

Does creating more composited layers always improve performance?

No. Independent layers can reduce repeated painting for certain updates, but each layer also has costs such as graphics memory consumption and rasterization or synchronization overhead. A page with excessive layers can therefore perform worse or consume substantially more memory. The useful question is whether the layer structure reduces the dominant workload for the specific interaction. Profiling should guide the decision rather than a rule that more layers are better.

How would you investigate a janky CSS animation?

I would record the interaction in browser performance tooling and determine whether frames are spending time in scripting, layout, painting, rasterization, or compositing. I would then inspect the animated properties and check whether the animation is causing repeated layout or paint work. If the workload is dominated by painting or layout, I would consider whether the visual effect can be expressed with compositor-friendly operations such as transforms or opacity. Finally, I would remeasure the change rather than assuming the optimization worked.