The will-change
CSS property provides a way for authors to hint browsers about the kind of changes to be expected on an element, so that the browser can set up appropriate optimizations ahead of time before the element is actually changed. These kind of optimizations can increase the responsiveness of a page by doing potentially expensive work ahead of time before they are actually required.
Proper usage of this property can be a bit tricky:
Don't apply will-change to too many elements. The browser already tries as hard as it can to optimize everything. Some of the stronger optimizations that are likely to be tied to will-change
end up using a lot of a machine’s resources, and when overused like this can cause the page to slow down or consume a lot of resources.
Use sparingly. The normal behavior for optimizations that the browser make is to remove the optimizations as soon as it can and revert back to normal. But adding will-change
directly in a stylesheet implies that the targeted elements are always a few moments away from changing and the browser will keep the optimizations for much longer time than it would have otherwise. So it is a good practice to switch will-change
on and off on using script code before and after the change occurs.
Don't apply will-change to elements to perform premature optimization. If your page is performing well, don't add the will-change
property to elements just to wring out a little more speed. will-change
is intended to be used as something of a last resort, in order to try to deal with existing performance problems. It should not be used to anticipate performance problems. Excessive use of will-change
will result in excessive memory use and will cause more complex rendering to occur as the browser attempts to prepare for the possible change. This will lead to worse performance.
Give it sufficient time to work. This property is intended as a method for authors to let the user-agent know about properties that are likely to change ahead of time. Then the browser can choose to apply any ahead-of-time optimizations required for the property change before the property change actually happens. So it is important to give the the browser some time to actually do the optimizations. Find some way to predict at least slightly ahead of time that something will change, and set will-change
then.
Be aware, that will-change may actually influence the visual appearance of elements, when used with property values, that create a stacking context (e.g. will-change: opacity), as the stacking context is created up front.
Initial value | auto |
---|---|
Applies to | all elements |
Inherited | no |
Media | all |
Computed value | as specified |
Animation type | discrete |
Canonical order | the unique non-ambiguous order defined by the formal grammar |
/* Keyword values */ will-change: auto; will-change: scroll-position; will-change: contents; will-change: transform; /* Example of <custom-ident> */ will-change: opacity; /* Example of <custom-ident> */ will-change: left, top; /* Example of two <animateable-feature> */ /* Global values */ will-change: inherit; will-change: initial; will-change: unset;
auto
The <animateable-feature>
can be one of the following values:
scroll-position
contents
<custom-ident>
unset
, initial
, inherit
, will-change
, auto
, scroll-position
, or contents
. The spec doesn't define the behavior of particular value, but it is common for transform
to be a compositing layer hint. Chrome currently takes two actions, given particular CSS property idents: establish a new compositing layer or a new stacking context.auto | <animateable-feature>#where
<animateable-feature> = scroll-position | contents | <custom-ident>
.sidebar { will-change: transform; }
The above example adds the will-change
property directly to the stylesheet, which will cause the browser to keep the optimization in memory for much longer than it is needed and we've already seen why that should be avoided. Below is another example showing how to apply the will-change
property through scripting, which is probably what you should be doing in most cases.
var el = document.getElementById('element'); // Set will-change when the element is hovered el.addEventListener('mouseenter', hintBrowser); el.addEventListener('animationEnd', removeHint); function hintBrowser() { // The optimizable properties that are going to change // in the animation's keyframes block this.style.willChange = 'transform, opacity'; } function removeHint() { this.style.willChange = 'auto'; }
It may however be appropriate to include will-change
in your style sheet for an application that does page flips on key presses like an album or a slide deck presentation where the pages are large and complex. This will let browser prepare the transition ahead of time and allow for snappy transitions between the pages as soon as the key is pressed.
.slide { will-change: transform; }
Specification | Status | Comment |
---|---|---|
CSS Will Change Module Level 1 The definition of 'will-change' in that specification. | Working Draft | Initial definition |
Feature | Chrome | Firefox (Gecko) | Internet Explorer | Opera | Safari (WebKit) |
---|---|---|---|---|---|
Basic support | 36 | 36 (36) [1] | No support | 24 | 9.1 |
Feature | Android | Firefox Mobile (Gecko) | IE Phone | Opera Mobile | Safari Mobile |
---|---|---|---|---|---|
Basic support | 37 | 36.0 (36) [1] | No support | No support | 9.3 |
[1] From Firefox 31 to 35, will-change
was available, but only if the user flipped the layout.css.will-change.enabled
flag to true
. The preference has been removed in Firefox 43.
Firefox allows to set will-change: will-change
up to version 42.0, which is invalid by the spec. This was fixed in Firefox 43.0. See bug 1195884.
© 2005–2017 Mozilla Developer Network and individual contributors.
Licensed under the Creative Commons Attribution-ShareAlike License v2.5 or later.
https://developer.mozilla.org/en-US/docs/Web/CSS/will-change