Projects Blog About Contact

Browser compositing layers

frontendcompositingbrowser-internalscssperformance

Layers are an implementation strategy

A browser compositing layer is a rendered surface that can be moved, clipped, transformed, blended, and assembled with other surfaces. Layers let the compositor update parts of the screen without repainting the entire page. They are essential for video, canvas, transforms, opacity animations, fixed elements, and complex scrolling.


graph TD
  DOM["DOM tree"] --> Render["render tree"]
  Render --> Paint["paint chunks/display lists"]
  Paint --> Layerize["layerization heuristics"]
  Layerize --> L1["layer texture: header"]
  Layerize --> L2["layer texture: content tiles"]
  Layerize --> L3["layer texture: modal"]
  L1 --> Composite["compositor frame"]
  L2 --> Composite
  L3 --> Composite

A layer is not the same as a DOM element and not the same as a stacking context, though they are related. The engine groups paint chunks into composited surfaces based on correctness and performance heuristics.

Why layers exist

If a modal fades in with opacity, the browser can rasterize the modal once, then blend it at different alpha values. If a carousel moves with transform, the compositor can shift its texture each frame. If every frame required layout and paint, smooth animation would be much harder.

Layers also support independent scrolling and fixed positioning. A fixed header can stay in place while content scrolls underneath. Large content layers can be tiled, rasterized incrementally, and reused.

How elements get promoted

Common promotion reasons include:

  • 3D or animated transforms.
  • Opacity animations.
  • Video, canvas, and plugins.
  • Fixed or sticky elements in certain contexts.
  • CSS filters or backdrop filters.
  • will-change.
  • Isolation needed for clipping, blending, or overlap correctness.

These are heuristics, not a public contract. Browser versions differ. The same CSS can layerize differently depending on device, memory pressure, and surrounding content.

Costs of layers

Layers consume memory because they need backing textures or tiles. A full-screen layer on a high-DPI device can be several megabytes. Many large layers can trigger tile eviction, re-rasterization, and GPU memory pressure.

Layers can also increase raster work. If you promote many cards in a scrolling list, the browser may need to raster each card separately. That can be worse than painting a shared surface.

Compositing has its own cost. Blending translucent layers, applying filters, and managing damage regions all take time. The compositor is fast, but it is not infinite.

Practical patterns

Promote around interactions, not permanently. A drawer or menu that animates frequently can justify a layer. A static card usually cannot.

.drawer[data-opening],
.drawer[data-closing] {
  will-change: transform;
}

Keep animated layers small. Animate the panel, not the full page wrapper. Avoid putting giant backgrounds, text-heavy content, and unrelated children into the same promoted surface if only a small part moves.

Use wrapper elements to separate layout from compositing. The outer element can reserve layout space; the inner element can transform.

.slot {
  inline-size: 320px;
  block-size: 220px;
}

.slot > .moving {
  transition: transform 180ms ease;
}

Failure modes

Unexpected stacking changes happen when layer-related properties create stacking contexts. transform, opacity < 1, filter, and will-change can affect painting order. A tooltip that used to appear above a sibling may suddenly sit underneath because it is trapped in a new stacking context.

Text rendering changes when text is rasterized into a composited layer, especially during fractional transforms. Users perceive this as blur or weight changes.

Layer explosion occurs when will-change is applied to every list item. The page may look fine in a simple test and fall apart with real data.

Backdrop filters are layer-hungry. They require sampling pixels behind the element and can cause large offscreen surfaces.

Diagnostics

Use DevTools Layers to inspect actual composited layers. Do not infer solely from CSS. In Performance traces, check whether frames spend time in paint, raster, or composite. Use layer borders and paint flashing to understand what is being repainted versus moved.

When debugging z-index issues, inspect stacking contexts as well as layers. The problem may be CSS painting order rather than GPU compositing.

When debugging memory, estimate layer size: width times height times DPR squared times four bytes, plus tiling overhead. A 1000 x 1000 CSS pixel layer at DPR 2 is roughly 16 MB before overhead.

Implementation patterns

Use layer promotion as an interaction-local tool. For a drawer, add the promotion class just before opening and remove it after the transition ends. For a reorderable list, promote the actively dragged item and perhaps the drop indicator, not every row. This keeps idle memory low and reduces the chance that scrolling has to manage dozens of retained textures.

Separate fixed visual effects from scrolling content. A blurred sticky header over a long list may force expensive backdrop sampling while the list scrolls. Often the better implementation is a small header surface with a simple translucent background, plus a separate shadow or border. If the design really needs backdrop blur, keep the filtered area small and test it on low-power devices.

Prefer transform and opacity for compositor-friendly animation, but do not treat that as a universal rule. Animating height in an accordion can be correct because surrounding content must move. The optimization question is whether the browser is doing the minimum necessary work for the intended effect. A transform animation that requires a huge promoted wrapper may be worse than a small layout animation.

Debugging layer bugs

When an animation janks, identify which pipeline stage is saturated. Paint flashing tells you whether pixels are being repainted. Layer borders show promoted surfaces. A performance trace shows raster threads, main-thread paint, and compositor work. If paint is cheap but raster is expensive, the problem may be texture size, image decoding, or filters. If composite is expensive, look for translucent overlap, backdrop filters, or too many moving layers.

For z-index reports, build a minimal stacking-context map. List every ancestor with position plus z-index, transform, opacity, filter, contain, isolation, or will-change. The bug often comes from a newly created context trapping an overlay, not from the compositor choosing the wrong layer.

Checklist

  • Treat layer promotion as a measured optimization.
  • Use will-change only for elements that will actually change.
  • Keep promoted surfaces small and short-lived.
  • Watch for stacking-context side effects.
  • Test text clarity during and after transforms.
  • Inspect actual layers in browser tooling.

Compositing layers are powerful because they let the browser reuse painted pixels. They become harmful when every element asks for its own surface. The goal is not “more layers”; it is the right layers for the interaction.

comments powered by Disqus