Going to make a change...
CSS will-change

Reading time: 4 minutes

The CSS ‘will-change’ property is the Eagle Scout of CSS properties, living up to the scout motto—Be Prepared! In terms of optimizing your design’s user experience, it prepares an element for animation before the animation actually happens. But why is this important, and what have we been doing up until now, if anything?

First, it’s important because animations come at a price. There are CSS 3D transformations and CSS 2D transformations. Examples of CSS transforms are rotate, scale, skew, translate, and matrix. Apple also has a good overview of both 2D and 3D transforms with some helpful visuals.

Besides the obvious fact that 2D transforms take place only in the X,Y axes while 3D transforms include the Z-axis, there’s another somewhat hidden difference in terms of performance, which translates to user experience. You see, CSS animations, transforms, and transitions are not automatically GPU accelerated, that’s to say, they don’t get help from your computer’s Graphics Processing Unit, which is there to help perform more of the complex graphical computations resulting in smoother animations. Consequently, if left to their own accord, they rely only on the user’s browser’s slower rendering engine. Long story short, that’s not as good as if the GPU was helping out with hardware acceleration.



Most modern browsers (including IE9+) now come with hardware acceleration built in, but they only utilize it when they have some reason to believe they need to do so. In terms of CSS, the strongest indication is given by convincing the browser that a 3D transformation is being applied to a given element, even when it’s really not for all intents and purposes—also known as a hack. For instance, you might add this line of CSS to a 2D animation to trick the browser into using 3D hardware acceleration:


transform: translate3d(0, 0, 0);


With the CSS will-change property, you no longer need that hack. So not only is the will-change property better prepared, but it’s also not a liar—well on its way to becoming an even better boy scout.

How does it work? The high-level view is that it’s a dedicated property to inform your browser to be ready for changes and to allocate memory to prepare for it. It’s kind of like letting your significant other know that this weekend we’re having date night with the neighbors, so don’t make any other plans and be on your best behavior. This gives him or her time to get mentally ready, maybe get a new outfit, a haircut, what have you. It’s just simple planning.

Where do we implement it?

A good example is in a hover statement in your CSS. For example:


.myDiv {
  transition: width 2s, height 2s, background-color 2s, transform 2s;

.myDiv:hover {
  will-change: transform;}

.myDiv:active {
  transform: rotate(180deg);


One of my general pet peeves about many HTML/CSS/JS examples is that to most of us they often appear to live in a vacuum without purpose. Even if they are pragmatic, it’s not always evident to most people. So where might this be applicable in real life? Perhaps a full screen slideshow or a CSS flip-book or animating the opening of a layer.

Take these two examples from Nikolay Talanov on Codepen, where the will-change property was implemented to produce a full-screen drag-slider (1st example) and some fancy page transitions with an off-canvas menu (2nd example). Nikolay first implemented the drag-slider without the will-change property, which he says resulted in a very laggy first drag event (like 100ms jank). After profiling with timeline, the problem was fixed by applying the will-change property to the .slide__bg element.

Drag slider using "will-change" CSS property




With all this said, not unlike most things, there is another side to the coin. Adding to the earlier date night analogy, to plan one every night of the week would be a serious misstep backfiring with the most unintended consequences to your relationship and social life. The likes of which would directly undermine what you had hoped to achieve through date-night in the first place.

Realize that your browser is already trying as hard as it can to optimize everything. Tying up your machine’s resources by applying the will-change property to too many elements can essentially have the opposite effect you’re going for, because you’re putting the browser ‘on-notice’ to set aside memory for something that may or may not even happen. Freeing up that memory for what does happen would be more desirable in such cases. Furthermore, you need to build in the removal of the will-change property by applying them to the pseudo class :hover or writing scripts that will intelligently switch the will-change property on and off appropriately if you don’t want to wind up with the opposite intended effect.