will-change in CSS: warning the browser before an expensive animation

On a complex animation, a slightly choppy scroll, or a transform that takes a moment to kick in, the culprit is often a browser caught off guard, preparing an optimization right as the animation starts instead of ahead of time. That is exactly the problem will-change is meant to solve.

It works like a heads-up given to the browser: this property is about to change, get ready in advance. Used well, it can make an animation noticeably smoother. Used carelessly, sprinkled everywhere out of habit, it produces the opposite effect.

Definition

will-change tells the browser that one or more CSS properties on an element are likely to change soon, for instance through a transition or a CSS animation. Knowing that ahead of time lets the browser set up certain optimizations behind the scenes, such as placing the element on its own graphics layer, before the change actually happens.

.animated-card {
  will-change: transform;
}
.animated-card:hover {
  transform: scale(1.05);
}

The properties targeted most often

will-change is most commonly paired with transform and opacity, the two properties animated most often and the most sensitive to rendering optimizations. Several properties can be targeted at once, separated by a comma, or the special values scroll-position and contents can be used for other kinds of changes.

The pitfall: a precaution that costs more than it saves

The most common mistake is adding will-change to a large number of elements just in case, on the assumption that it cannot hurt. That assumption is wrong: every element flagged with will-change can get its own dedicated graphics layer in memory, even if it never actually changes. On a page with dozens of elements marked this way, memory usage climbs noticeably, to the point of slowing the whole page down instead of speeding it up.

will-change and stacking contexts

Creating a new graphics layer with will-change also creates, as a side effect, a new stacking context, which can change the display order of nearby elements that use z-index. That detail sometimes explains unexpected overlaps on an interface that is otherwise built correctly.

will-change and scrolling

The scroll-position value targets a rarer case: a container about to scroll programmatically, for instance during a smooth JavaScript-driven scroll toward a specific section of the page. It readies the browser for that internal motion, much like transform readies it for a visual animation, but it sees far less use in practice than transform and opacity. It is reserved for cases where an expensive JavaScript-driven scroll causes a measurable slowdown, not by default on an ordinary container with overflow: auto.

Frequently asked questions

No, definitely not as a default habit. will-change is reserved for animations that are genuinely expensive or noticeably choppy, not every small hover effect: on simple, short transforms, the browser already optimizes very well without any extra hint.

No, it is only a hint given to the browser, not a guarantee. The browser remains free to ignore it, especially if it decides too many dedicated layers already exist, and heavy JavaScript running in parallel can still make the animation choppy despite will-change.

It is best removed once the animation finishes, typically through JavaScript listening for the transition or animation end event, rather than left in place indefinitely, which would pin a graphics layer in memory for no reason once the effect is over.