will-change & Layer Promotion

What will-change Actually Does

will-change is one of those CSS properties that sounds harmless but can absolutely wreck your performance if you misuse it. It is a hint to the browser: "This property will change soon. Prepare for it." For compositor properties (transform, opacity), the browser's preparation is layer promotion — moving the element to its own compositing layer backed by a GPU texture.

.card {
  will-change: transform;
  /* Browser immediately creates a separate GPU layer for this element */
}

Without will-change, the browser may need to promote the element when the animation starts, causing a visible hitch (the first frame includes rasterization + GPU upload). With will-change, the layer is ready before the animation begins.

The Memory Cost of Layers

And here is where people get burned. Each compositing layer is a GPU texture, and textures are not free. The memory cost is:

Memory = width × height × devicePixelRatio² × 4 bytes (RGBA)

When to Use will-change

Correct: Before a Known Animation

// Apply before animation starts
card.addEventListener('pointerenter', () => {
  card.style.willChange = 'transform';
});

card.addEventListener('transitionend', () => {
  card.style.willChange = 'auto'; // Release the layer
});

/* Or with CSS: promote only in interactive context */
.card:hover {
  will-change: transform;
}
.card:active {
  transform: scale(0.98);
}

Correct: Always-Animated Elements

/* Persistent animations that run continuously */
.loading-spinner {
  will-change: transform;
  animation: spin 1s linear infinite;
}

Wrong: Blanket Application

/* ❌ NEVER do this */
* {
  will-change: transform;
}

/* ❌ Promoting elements that won't animate */
.static-header {
  will-change: transform; /* Why? It never moves. */
}

/* ❌ Too many properties */
.element {
  will-change: transform, opacity, top, left, width, height, color;
}

Implicit Layer Creation

Here is the thing most people miss: elements can be promoted to layers without you ever writing will-change:

Direct Triggers

/* 3D transforms always create a layer */
.element { transform: translateZ(0); }        /* The classic 'hack' */
.element { transform: translate3d(0, 0, 0); } /* Same effect */

/* Active CSS animations/transitions on compositor properties */
.element { transition: transform 0.3s; }
/* Layer created when transition starts, released when it ends */

/* Specific element types */
video { }    /* Always composited */
canvas { }   /* Always composited (hardware-accelerated) */
iframe { }   /* Composited for cross-origin isolation */

Overlap Promotion (Squashing)

And this is the one that really catches you off guard. When a composited element overlaps a non-composited element, the browser may promote the overlapping element to maintain correct stacking order:

<div class="background">...</div>
<div class="animated" style="will-change: transform;">...</div>
<div class="tooltip">I overlap the animated div</div>

The tooltip overlaps .animated (which is composited). To render the tooltip on top of the animated layer, the browser must also composite the tooltip. This is called overlap promotion.

The overlap promotion cascade

Overlap promotion can cascade: element A is composited, B overlaps A (promoted), C overlaps B (promoted), D overlaps C (promoted). A single will-change on element A causes three additional layers. In complex layouts with absolute/fixed positioning, this can create dozens of unintended layers. Use the Layers panel in DevTools to inspect why elements are composited — it shows the "compositing reason" for each layer.

The Layer Explosion Antipattern

This is the part that silently destroys mobile performance. Layer explosion occurs when too many layers are created, overwhelming GPU memory:

/* Common in carousels, dashboards, complex UIs */
.card {
  will-change: transform;  /* 50 cards × large layers = hundreds of MB */
}
.tooltip {
  will-change: opacity;    /* Tooltips for every element */
}
.icon {
  transform: translateZ(0); /* "Performance optimization" that isn't */
}

Symptoms:

• Rendering becomes slower, not faster
• Mobile tabs crash or reload
• DevTools Layers panel shows 100+ layers
• Memory usage spikes in Task Manager

Debugging with the Layers Panel

Chrome DevTools → More tools → Layers:

1. Layer count: Total number of compositing layers. Healthy pages have 5-20 layers. Above 50 warrants investigation.
2. Layer sizes: Dimensions and memory per layer. Look for unexpectedly large layers.
3. Compositing reasons: Why each element was promoted. Common reasons:
   • "Has a will-change hint"
   • "Is a 3D transformed element"
   • "Has an active accelerated animation"
   • "Overlaps other composited content"
4. Paint count: How many times each layer has been repainted. Layers with high paint counts during animation indicate the animation is not compositor-only.

Best Practices

Dynamic will-change

// Apply when animation is imminent, remove when done
function animateElement(el) {
  el.style.willChange = 'transform';

  requestAnimationFrame(() => {
    el.style.transform = 'translateX(100px)';

    el.addEventListener('transitionend', () => {
      el.style.willChange = 'auto';
    }, { once: true });
  });
}

CSS-Only Dynamic Promotion

/* Layer created only during interaction */
.card {
  transition: transform 0.3s ease;
}
.card:hover {
  will-change: transform;
}
.card:active {
  transform: scale(0.97);
}
/* No persistent layer cost for non-hovered cards */

Contain Layer Size with contain: size

.widget {
  will-change: transform;
  contain: size layout;
  width: 300px;
  height: 200px;
  /* Browser knows the exact layer dimensions upfront */
}