GPU Compositing: transform vs left/top

Two Animations, Wildly Different Performance

Pop quiz before we even start: these two CSS animations produce the exact same visual result — moving a box 300px to the right. One runs at 60fps on a budget phone. The other drops frames on a high-end desktop. Can you guess which is which?

/* ❌ Animates left — triggers layout + paint + composite every frame */
@keyframes move-left {
  from { left: 0; }
  to { left: 300px; }
}

/* ✅ Animates transform — triggers composite only */
@keyframes move-transform {
  from { transform: translateX(0); }
  to { transform: translateX(300px); }
}

Same pixels, wildly different performance. Understanding why requires knowing how the browser's compositing architecture works.

The Full Pipeline vs Compositor-Only

When you animate left:

Every frame:
  Main Thread: Style → Layout → Paint → [hand off]
  Compositor Thread: Composite → GPU → Screen

When you animate transform:

Every frame:
  Main Thread: (nothing — not involved)
  Compositor Thread: Apply transform to existing texture → GPU → Screen

Compositor-Only Properties

So which properties get this special treatment? Only four CSS properties can be animated entirely on the compositor thread:

Everything else — left, top, width, height, margin, padding, border, font-size, color, background — requires the main thread for either layout recalculation, repaint, or both.

How GPU Textures Work

To understand why this is fast, you need to know what happens under the hood. When an element is promoted to its own compositing layer, the browser:

1. Paints the element into a bitmap (rasterization)
2. Uploads that bitmap to the GPU as a texture
3. Stores the texture in GPU memory (VRAM)
4. Composites by positioning textures relative to each other

The texture is basically a screenshot — once painted and uploaded, the compositor can move, rotate, scale, or fade it without ever repainting. This is the key insight behind why transform and opacity are fast: the compositor just shuffles existing textures around rather than generating new ones.

Main Thread                    GPU Memory
┌──────────┐                  ┌──────────────────┐
│ Paint     │ ──rasterize──→ │ Texture: Layer 1  │
│ element   │    upload       │ (bitmap of pixels)│
└──────────┘                  └──────────────────┘

Compositor Thread             GPU
┌──────────┐                  ┌──────────────────┐
│ Transform │ ──move/scale──→ │ Draw texture at   │
│ the layer │   the texture   │ new position      │
└──────────┘                  └──────────────────┘

Layer Creation: What Gets Promoted

The browser promotes elements to their own compositing layers when:

/* Explicit promotion */
.promoted {
  will-change: transform;  /* Tells browser: I'll animate this */
  transform: translateZ(0); /* Old hack, same effect */
}

/* Implicit promotion */
.video-element { }          /* <video> elements */
.canvas-element { }         /* <canvas> elements */
.has-3d-transform {
  transform: rotate3d(1, 0, 0, 45deg);  /* Any 3D transform */
}
.fixed-element {
  position: fixed;           /* Fixed positioning (in many browsers) */
}
.animated {
  animation: slide 1s;       /* Active CSS animation on compositor property */
  transition: transform 0.3s; /* Active CSS transition on compositor property */
}

Elements also get promoted when they overlap a composited layer and the browser cannot determine stacking order without a separate layer (squashing heuristic).

Practical Animation Comparisons

Slide-In Animation

/* ❌ Layout every frame */
.panel-left {
  position: absolute;
  transition: left 0.3s ease;
  left: -300px;
}
.panel-left.open {
  left: 0;
}

/* ✅ Compositor only */
.panel-transform {
  transform: translateX(-100%);
  transition: transform 0.3s ease;
}
.panel-transform.open {
  transform: translateX(0);
}

Fade + Scale Entrance

/* ✅ All compositor properties */
.card-enter {
  opacity: 0;
  transform: scale(0.95) translateY(10px);
  transition: opacity 0.2s, transform 0.3s ease-out;
}
.card-enter.visible {
  opacity: 1;
  transform: scale(1) translateY(0);
}

Expanding Card (Layout Required)

Sometimes you genuinely need layout to change — surrounding elements must reflow:

/* When layout change is intentional, minimize the damage */
.expandable {
  contain: layout style;  /* Limit reflow scope */
  transition: height 0.3s ease;
  overflow: hidden;
}

If layout change is only visual (no sibling reflow needed), use scale instead:

.expandable-visual {
  transform-origin: top left;
  transition: transform 0.3s ease;
}
.expandable-visual.expanded {
  transform: scaleY(1.5);
}

Measuring the Difference in DevTools

Rendering Tab

1. Open DevTools → More tools → Rendering
2. Enable "Paint flashing" — green overlays show repainted areas
3. Enable "Layer borders" — orange borders show composited layers

With left animation: green flash on every frame (repainting). With transform animation: no green flash (compositor only, no repaint).

Performance Panel

Record the animation and compare:

• left: Style, Layout, Paint, and Composite events every frame
• transform: Only Composite events — Style, Layout, and Paint are absent

The Cost Hierarchy

Not all CSS properties are created equal when it comes to animation cost:

Cheapest → Most Expensive:

1. transform, opacity    → Composite only (compositor thread)
2. color, background     → Paint + Composite (main thread, no layout)
3. font-size, padding    → Layout + Paint + Composite (main thread, full pipeline)
4. top/left + siblings   → Layout (affecting many elements) + Paint + Composite