CSS Will Change

Imagine a moving crew that shows up to a house without any warning, they have to figure out on the spot which items are heavy and plan the truck layout while everyone is already waiting. If you call ahead and tell them exactly which rooms have the heavy furniture, they can bring the right equipment in advance and the move goes much faster. will-change is that phone call to the browser. It warns the browser ahead of time that a specific property, like transform or opacity, is about to change, so the browser can prepare an optimized rendering layer before the animation starts instead of scrambling mid-animation.

In this page:

What will-change Actually Does
When to Use will-change
Optimizing transform Animations
Optimizing opacity Animations
The Overuse Warning

What will-change Actually Does

will-change tells the browser to create a new compositor layer for an element ahead of time, so that when the promised property changes, the browser can animate it cheaply without recalculating the whole page layout.

Note: Only list the specific properties you intend to animate, such as will-change: transform, rather than the vague will-change: auto.

Warning: will-change is a hint, not a guarantee, browsers may ignore it under memory pressure or if too many elements request it simultaneously.

Example: What will-change Actually Does

css

.box {
  will-change: transform;
}

When to Use will-change

will-change is most valuable right before a known, upcoming animation, for example just before a modal slides in or a sidebar expands, rather than being applied constantly to every animated element on the page.

Note: Add will-change through JavaScript just before triggering an animation and remove it once the animation event finishes for the most efficient usage pattern.

Warning: Applying will-change to dozens of elements at page load can force the browser to allocate many compositor layers upfront, increasing memory usage before any animation even runs.

Example: When to Use will-change

css

.modal.about-to-open {
  will-change: transform;
}

Optimizing transform Animations

transform changes, such as translate, scale, and rotate, can run entirely on the compositor thread when will-change is set, keeping animations smooth even while the main thread is busy.

Note: Prefer transform: translate() over changing top and left for moving elements, since transform can be composited while position changes cannot.

Warning: will-change: transform does not help if the animation also triggers layout changes elsewhere, such as resizing a sibling element.

Example: Optimizing transform Animations

css

<style>
.box {
  will-change: transform;
  transition: transform 0.3s;
  background: teal;
  color: white;
  padding: 12px;
  display: inline-block;
}
.box:hover {
  transform: translateX(50px);
}
</style>
<div class="box">Runs on the compositor thread</div>

Optimizing opacity Animations

Like transform, opacity can be animated entirely on the compositor thread, making fade transitions on modals, tooltips, and overlays especially good candidates for will-change.

Note: Combine will-change: opacity with transition: opacity for the smoothest possible fade effects on frequently toggled elements like tooltips.

Warning: Setting will-change: opacity on an element that rarely changes wastes the compositor layer it creates, only apply it to elements that fade often.

Example: Optimizing opacity Animations

css

<style>
.tooltip {
  will-change: opacity;
  opacity: 0;
  transition: opacity 0.2s;
  background: #333;
  color: white;
  padding: 8px 12px;
  display: inline-block;
}
.tooltip.visible {
  opacity: 1;
}
</style>
<div class="tooltip visible">Fades smoothly</div>

The Overuse Warning

Because every will-change declaration can create a new GPU-backed layer, marking too many elements consumes significant graphics memory and can paradoxically make scrolling and animations feel slower rather than faster.

Note: Remove will-change from an element once its animation is complete, either by toggling a class or resetting the property back to auto in JavaScript.

Warning: Never apply will-change: transform, opacity to a global selector like * or body, this creates a compositor layer for every single element on the page.

Example: The Overuse Warning

css

/* Avoid: creates a compositor layer for every element on the page */
* {
  will-change: transform;
}

Common Mistakes

Applying will-change to many elements at once as a blanket performance fix, which can consume excessive memory and actually slow the page down.
Leaving will-change permanently set on an element long after its animation has finished, wasting browser resources indefinitely.
Using will-change: contents when the intended change is actually to transform or opacity, mismatched hints provide no benefit.

Chapter Summary

will-change hints to the browser that a property is about to change, allowing it to optimize rendering in advance.
It works best with transform and opacity, since those properties can be animated on the compositor without triggering layout or paint.
Apply will-change shortly before an animation starts and remove it afterward, overusing it permanently can hurt performance instead of helping.

Browser Support

will-change is supported by all modern browsers; browsers that do not recognize it simply ignore the hint with no negative effect.

🔒

Chapter Quiz — Complete all 25 topics to unlock

0/25 topics done

Complete these topics first:

← Previous Lesson CSS Cursor Next Lesson → CSS User Interface