Skip to content

Commit 5e95974

Browse files
tabatkinstabatkins
committed
[css-will-change] Move and massively expand the usage advice.
--HG-- extra : rebase_source : 7a30b5df0c5e5525d0c55604bb3d164ee2d52692
1 parent 69b12f3 commit 5e95974

2 files changed

Lines changed: 265 additions & 35 deletions

File tree

‎css-will-change/Overview.bs‎

Lines changed: 125 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -36,6 +36,131 @@ Introduction</h2>
3636
This way, when the actual change happens,
3737
the page updates in a snappy manner.
3838

39+
<h3 id='using'>
40+
Using 'will-change' Well</h3>
41+
42+
The 'will-change' property,
43+
like all performance hints,
44+
can be somewhat difficult to learn how to use “properly”,
45+
particularly since it has very little, if any, effect an author can directly detect.
46+
However, there are several simple “Dos and Don'ts”
47+
which hopefully will help develop a good intuition about how to use 'will-change' well.
48+
49+
<h4 id='dont-global' class='no-num no-toc'>
50+
Don't Spam 'will-change' Across Too Many Properties or Elements</h4>
51+
52+
A common initial response to seeing 'will-change' is to assume that code like this is a good idea:
53+
54+
<pre>* { will-change: all; }</pre>
55+
56+
After all, this tells the browser to go ahead and optimize everything,
57+
which has to be good right?
58+
59+
Wrong. The browser <em>already</em> tries as hard as it can to optimize everything.
60+
Telling it to do so explicitly doesn't help anything,
61+
and in fact has the capacity to do a lot of harm;
62+
some of the stronger optimizations that are likely to be tied to 'will-change'
63+
end up using a lot of a machine's resources,
64+
and when overused like this can cause the page to slow down or even crash.
65+
66+
In addition, 'will-change' does have <strong>some</strong> side-effects,
67+
and it's very unlikely that pages actually want all those side-effects on every element.
68+
69+
<h4 id='css-sparingly' class='no-num no-toc'>
70+
Use 'will-change' Sparingly In Stylesheets</h4>
71+
72+
Using 'will-change' directly in a stylesheet
73+
implies that the targeted elements are always a few moments away from changing.
74+
This is <em>usually</em> not what you actually mean;
75+
instead, 'will-change' should usually be flipped on and off via scripting
76+
before and after the change occurs (see <a section href="#dont-waste"></a>).
77+
However, there are some common circumstances in which it is appropriate to use 'will-change' directly in a stylesheet.
78+
79+
<div class='example'>
80+
For example,
81+
specifying 'will-change' for a small number of persistent UI elements in a page
82+
which should react snappily to the user
83+
is appropriate:
84+
85+
<pre>
86+
body > .sidebar {
87+
will-change: transform;
88+
/* Will use 'transform' to slide it out
89+
when the user requests. */
90+
}
91+
</pre>
92+
93+
Because this is limited to a small number of elements,
94+
the fact that the optimization is rarely actually used
95+
doesn't hurt very much.
96+
</div>
97+
98+
<div class='example'>
99+
Sometimes an element really <em>does</em> change a property nearly constantly.
100+
Perhaps it responds to the user's mouse movements,
101+
or just regularly takes some action that causes an animation.
102+
In this case, just declaring the 'will-change' value in the stylesheet is fine,
103+
as it accurately describes that the element will regularly/constantly change,
104+
and so should be kept optimized.
105+
106+
<pre>
107+
.cats-flying-around-the-screen {
108+
will-change: left, top;
109+
}
110+
</pre>
111+
</div>
112+
113+
<h4 id='give-time' class='no-num no-toc'>
114+
Give 'will-change' Sufficient Time To Work</h4>
115+
116+
Another common bad pattern is to apply 'will-change' to an element
117+
<em>immediately</em> before starting the animation or property change that it's meant to help with.
118+
Unfortunately, most of those optimizations need time to be applied,
119+
and so they don't have enough time to set-up when this is done,
120+
and the 'will-change' has little to no effect.
121+
Instead, find some way to predict at least slightly ahead of time that something will change,
122+
and set 'will-change' <em>then</em>.
123+
124+
<div class='example'>
125+
For example,
126+
if an element is going to change when a user clicks on it,
127+
setting 'will-change' on hover will usually give at least 200 milliseconds
128+
for the optimizations to be set up,
129+
as human reaction time is relatively slow.
130+
This can be done either via scripting,
131+
or rather simply with a CSS rule:
132+
133+
<pre>
134+
.element { transition: opacity .2s; opacity: 1; }
135+
.element:hover { will-change: opacity; }
136+
.element:active { opacity: .3; }
137+
</pre>
138+
139+
However, a rule like that is useless if the effect is going to happen on hover.
140+
In cases like these, it is often still possible to find some way to predict the action before it occurs.
141+
For example, hovering an ancestor may give enough lead time:
142+
143+
<pre>
144+
.element { transition: opacity .2s; opacity: 1; }
145+
.container:hover > .element { will-change: opacity; }
146+
.element:hover { opacity: .3; }
147+
</pre>
148+
</div>
149+
150+
<h4 id='dont-waste' class='no-num no-toc'>
151+
Don't Waste Resources On Elements That Have Stopped Changing</h4>
152+
153+
Because the optimizations browsers use for changing some properties are expensive,
154+
browsers remove them and revert to normal behavior as soon as they can in normal circumstances.
155+
However, 'will-change' will generally override this behavior,
156+
maintaining the optimizations for much longer than the browser would otherwise do.
157+
158+
As such, whenever you add 'will-change' to an element,
159+
especially via scripting,
160+
don't forget to <em>remove</em> it after the element is done changing,
161+
so the browser can recover whatever resources the optimizations are claiming.
162+
163+
39164
<h2 id='will-change'>
40165
Hinting at Future Behavior: the 'will-change' property</h2>
41166

@@ -64,17 +189,6 @@ Hinting at Future Behavior: the 'will-change' property</h2>
64189
when they have ''will-change: transform'' specified
65190
might avoid doing that when there are <em>too many</em> elements declaring that,
66191
to avoid exhausting GPU memory.
67-
68-
Authors should avoid overusing this property,
69-
and shouldn't apply it to an element unless it is known (or expected)
70-
that the element will change in the indicated way soon.
71-
For example, applying 'will-change' to an element from a static CSS stylesheet
72-
is probably an error;
73-
most of the time,
74-
'will-change' should be applied by scripting,
75-
some time shortly before starting an animation or other change,
76-
and should be promptly reset to its initial value of ''auto''
77-
when the element stops changing.
78192
</div>
79193

80194
Values have the following meanings:

0 commit comments

Comments
 (0)