CSS Will Change

Advanced

CSS `will-change` is a rendering hint: it tells the user agent which kind of change an element is expected to undergo soon so the user agent can prepare for potentially expensive rendering work ahead of time. It does not make the named change happen, and it does not guarantee a particular optimization such as GPU promotion.

This lesson owns the `will-change` property. Transforms, Animations, Transitions, and other lessons own the properties or mechanisms being changed; `will-change` only communicates anticipated future changes to the renderer. It should therefore not become a substitute for learning or applying the actual property.

Start with auto

The initial value is `auto`. It expresses no particular author intent and lets the user agent use its normal heuristics. In ordinary CSS, this is the right baseline: browsers already optimize rendering without requiring authors to predict every future change.

?

Name a property that is expected to change

A custom-ident value can name a CSS property whose value the author expects to change in the near future. The current draft also defines the special values `scroll-position` and `contents`. A shorthand property name communicates the expectation for the longhands that shorthand expands to.

The hint does not itself change `transform`. The `transform` declaration remains the mechanism that changes the element. `will-change: transform` only tells the user agent to expect that change.

?

Understand scroll-position and contents

`will-change: scroll-position` tells the user agent that the element's scroll position is expected to change soon. `will-change: contents` indicates that the contents of the element are expected to change. The current draft notes that `contents` can affect how much of a subtree the browser keeps optimized, so placing it high in the document can be expensive.

?

Use will-change sparingly

The current draft explicitly warns against applying `will-change` broadly, such as to every element. Optimizations can consume significant resources, and keeping them active longer than necessary can make performance worse. A useful rule is to hint at a small number of elements when there is a real, predictable upcoming change, and to remove the hint when the change is finished if it was applied dynamically.

A narrow hint can be useful when the author can predict a change slightly before it begins. The current specification gives examples such as preparing a small persistent sidebar or using an ancestor interaction to provide lead time. It does not require or promise a specific rendering strategy.

?

Know the side effects

`will-change` is not purely advisory in every observable respect. If a named non-initial property would create a stacking context, the specification requires `will-change` to create that stacking context in advance. It can likewise cause the element to generate containing blocks for absolutely or fixed positioned descendants when the anticipated property would do so.

The important lesson is not to memorize a particular browser implementation. Read `will-change` as a specification-defined hint with possible rendering side effects, not as a promise that the browser will perform a particular optimization.

?

Keep ownership boundaries clear

Use Transforms, Animations, Transitions, Scrolling, or the relevant property lesson to learn the actual behavior you want. Use Will Change only for the renderer hint. Do not use it as a generic performance switch, and do not treat a successful parse as evidence that a particular optimization will occur.

Summary