An Introduction to the CSS will-change Property

By Nick Salloum

In this article, we’re going to take a look at the CSS will-change property, what it is, when and how to use it, and how not to use it. There’s quite a bit of technical documentation available with regards to will-change, so I’ll reference a lot of those resources throughout this article, and compile them in a list at the end. This article will serve as an overview of the important parts with some quick examples.

Some Background

Today many front-end developers are leveraging CSS3 transitions, transforms, and animations to add a new layer of application interactivity that was previously left up to JavaScript libraries or Flash. Now we’re able to perform smooth and beautiful animations with minimal CSS. If you’ve been experimenting with and utilising these CSS3 properties, you’ve likely come across the terms CPU, GPU, and hardware acceleration. Let’s break these terms down quickly:

  1. The CPU, or the Central Processing Unit, is the piece of hardware that processes pretty much every computer operation. It’s otherwise known as the motherboard.
  2. The GPU, or the Graphics Processing Unit, is the piece of hardware associated with processing and rendering graphics. The GPU is designed to perform complex graphical computations and offloads some serious process weight from the CPU.
  3. Hardware acceleration is a general term for offloading CPU processes onto another dedicated piece of hardware. In the world of CSS transitions, transforms, and animations, it implies that we’re offloading the process onto the GPU, and hence speeding it up. This occurs by pushing the element to a layer of its own, where it can be rendered independently while undergoing its animation.

How does this improve the performance and quality of animations? Well, for starters, on WebKit-based browsers, we may often see a flicker when performing some CSS operations, namely 2D transforms and animations. In the past, we’ve gotten around this by tricking the browser a little. We would make the browser thing it was performing a 3D transform, thus offloading the operation onto the GPU. That’s because 3D transforms are automatically moved there. That leads us to some trickery like this:

.accelerate {
  -webkit-transform: translate3d(0, 0, 0);

There are some similar tricks, but for the most part, this covers us. However, this is a hack, and this is where the will-change property will help us out greatly, when used correctly. Let’s investigate.

What is will-change?

According to the W3C editor’s draft:

The will-change CSS property … allows an author to inform the UA ahead of time of what kinds of changes they are likely to make to an element. This allows the UA to optimize how they handle the element ahead of time, performing potentially-expensive work preparing for an animation before the animation actually begins.

This means that instead of forcing our transforms onto the GPU via a 3D transform hack, we can now use a dedicated property to inform the browser to look out for changes in the future, and optimise and allocate memory accordingly. Sounds pretty neat, right? Before we get all excited though, we need to understand how to use will-change.

How is will-change used?

The will-change property is only effective when used at a certain time. We can’t apply something like will-change: transform to an already-transforming element — it just doesn’t make sense. Sara Soueidan discusses this in fantastic detail on the Opera blog, so be sure to check that out, but the key points to note are these:

  1. We’re interested in using this property to let the browser know ahead of time what changes on an element can be expected.
  2. This allows the browser to make the proper optimizations in advance, ultimately leading to quicker and snappier rendering.
  3. As mentioned before, the browser needs to know ahead of time what changes will occur. This means that we have to think in advance when to prepare the browser for the change.

With the above points in mind, let’s look at an example that will have no effect:

.will-change:active {
  will-change: transform;
  transition: transform 0.3s;
  transform: scale(1.5);

Here, a change is already taking place by the time we inform the browser, totally cancelling out the whole point of the will-change property. If we want the browser to know ahead of time when to expect changes, we will have to inform it at the right moment.

For an element to achieve an active state, it must first be hovered. We can then do something like this:

.will-change {
  transition: transform 0.3s;

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

.will-change:active {
  transform: scale(1.5);

This small example gives us some insight into the thought process needed to properly use the will-change property. But before we continue with more examples, we need to be aware of some important considerations.

Browsers, by nature, try their absolute best to optimise and be prepared for changes. Browsers will remove certain optimizations as soon as they can in order to free up memory. Using the will-change property directly on an element, though, insists to the browser that the element in question is always very close to a change. This forces the browser to maintain optimizations, thus increasing memory consumption. With that in mind, we need to have a way of adding and removing the will-change property at the right times. The first example does this for us, because the property will only get added on hover. But what if we wanted the transform to actually occur on hover? You might be tempted to do this:

.will-change {
  will-change: transform;
  transition: transform 0.3s;

.will-change:hover {
  transform: scale(1.5);

This will result in an increase in memory consumption though, because we’re forcing the browser into thinking that the element is close to being changed at all times. We can get around this by instead looking for a hover event on the parent container:

.will-change-parent:hover .will-change {
  will-change: transform;

.will-change {
  transition: transform 0.3s;

.will-change:hover {
  transform: scale(1.5);

This adds the optimization when the mouse enters the parent container, and removes it when the mouse leaves. It also, however, implies that every time the mouse enters the parent container, the browser can expect a change on the element. This isn’t necessarily the case, and presents a perfectly clear example of how easy it is to abuse this property.

Building a full-screen slideshow or CSS flip-book of some sort is an example of when direct application could work. Slides will always need to be changed, so doing something like the following might be suitable:

.slide {
  will-change: transform;

Always Remove will-change

Always remember to remove the will-change property when you’re finished using it. As I mentioned above, browser optimizations are a costly process and so when used poorly they can have adverse effects. We can handle this with JavaScript, and we’ll reference a script from MDN to build a rough case example. Imagine we have an element with a class of element, and when we click on it, it gets transformed. Our CSS could look like this:

.element {
  transition: transform 0.5s;

.element.clicked {
  transform: scale(1.5);

If we want to notify the browser to prepare optimizations for a change that’s about to happen in response to a click on an element, we can do something like this:

var el = document.querySelector('.element');

el.addEventListener('mouseenter', hintBrowser);
el.addEventListener('animationEnd', removeHint);

function hintBrowser() { = 'transform';

function removeHint() { = 'auto';

Of course, you’d need to include the necessary JavaScript to add the correct clicked class when the element is actually clicked, but the above script should give you some insight into how to prepare the browser for changes, and to release memory once the changes are complete. When the mouse enters the element, the will-change property is added. When it’s clicked and the transform occurs (by your corresponding script), animation events will be sent out. On animationEnd we’ll remove the will-change property, freeing up memory once again.

Browser Support

The will-change property is fairly new, and is currently supported by the following browsers according to Can I Use:

  • Chrome 36 and up
  • Firefox 36 and up
  • Opera 24 and up
  • Android browser 37
  • Chrome for Android 40
  • Opera Mobile 24

Internet Explorer is the only major missing browser and will-change is listed as under consideration as of this writing.

Final Notes and Sources

The CSS will-change property can do just as much good as it can harm. This statement isn’t meant to deter you from using it, but acts as an advisory. There’s no reason to not consider it in your modern application builds, but just be mindful of all the potential issues I’ve pointed out. I hope you gained some insight into the wild world of browser optimizations, and can take this knowledge forward into your future projects.

There are a few articles that get into some detail about hardware acceleration and the will-change property. I recommend reading up on them as well to firm up your understanding of this umbrella of CSS.


Wow, what a great article. You read my mind throughout the article, answering every question I thought of during the process. For example, what if the transformation will happen during hover. Great job thumbsup .


Thanks for the article, Nick.

I find will-change to be an interesting animal. It is the first CSS property, as far as I know, that exists solely for optimization. It's not presentational and it doesn't introduce new functionality. It's more like a config setting, really.

I've noticed that the old "throw a Z transform" trick often comes with an annoying drawback: it ruins anti-aliasing on text. Many browsers will degrade to full-pixel or even nearest-neighbor anti-aliasing, since it's faster to animate. It's not as noticeable during movement, but when the text is just sitting still waiting to move, it's ugly. I just tested on my Mac/Chrome, and will-change seems to have a similar effect (it drops sub-pixel anti-aliasing for full-pixel anti-aliasing -- not the worst, but the behavior is still there). Hopefully future implementations will remedy this.

To be honest, working with will-change feels like superstition to me. Setting it often seems to have no discernible impact on framerate. And I'm always afraid of over doing it by putting it on too many elements, leading to thrashing in memory -- especially on mobile devices. And then there's the thought that will-change is just a request. The browser has its own decision making process and may decide it doesn't want to commit the memory for it.

Not saying it's bad, just voicing my own experience. Even the MDN article says usage is "a bit tricky" and then gives 4 paragraphs of advice. And you know, despite your advice, there are surely developers out there slapping * { will-change: all; } at the top of their stylesheets. smile


I cannot see how this acticle can be correct. You are suggesting to use will-change in a very awkward and complicated way, setting it on other element states that hopefully somehow precede the real will-change animation (and you can see from your own examples already how that doesn't really translate well). To save some memory? Isn't the exact point of will-change that it sits in memory so it's fast? How would you even deploy this way of thinking on mobile, where you have to work with even fewer pseudoclasses, :hover being unavailable per say? Additional media queries to address a different position for the will-change property because your hacky pseudoclasses don't work anymore? I have a feeling you're selling bad practice here. If I am wrong and will-change is indeed designed to be used as such, I will be moving all my animation logic into requestAnimationFrame() due to the silliness factor. This is definitely not the clean CSS I want to be writing.


First of all, throughout this article, I've only referenced the very curators of this property, i.e. the W3C. Every other reference that I've used references them directly too. While I have formulated my own opinions about this property, the technical implementations are based entirely off of these references. Therefore, saying that the article is incorrect is therefore saying that these sources, are too, incorrect.

Secondly, let's examine the property a little bit with a picture painted scenario. Let's just say we have an application running. Our machine allocates 100 units of generic memory evenly to our application, and it's running 10 different tasks. It tries to optimise accordingly as much as it can, but it defaults to even distribution, so each task takes on 10 units of memory. Somewhere, coming up, we have an animation that needs to happen. That animation can indeed work with 10 units of memory, but will be much smoother if it had 15. We also know that other tasks can also take a temporary memory hit, because they can all perform just fine with as low as 8 units of memory. Right before the machine needs to conjure up this animation, we can inform it to temporarily redistribute the memory, using the will-change property. The animation occurs smooth as ever, and once it's finished, the memory gets re-allocated evenly.

This is how will-change works. I mentioned over and over in the article that it simply cannot be abused, because applying it to many elements will produce a permanent performance hit on everything else, and will have an overall negative effect. It simply needs to be applied right before the animation, and removed right after.


I think you didn't answer how you can use these techniques on mobile, where is no :hover state. And I guess on mobiles would the memory issue be much more crucial than on desktops. Also I would like to see some kind of practical evidence. E.g. have you done some tests to validate your assumptions? Thanks.


I was going to say something very similar but I wouldn't put the lack of documentation for "will-change" on mobile all on him. What he's saying here reflects what a lot of other articles say and none of them touch on the mobile problem.

This is the root issue with "will-change" for me. In order to get it right it needs a way for the user to hint at its need ( ie. with a mouse ). I haven't personally spent a ton of time thinking about how it would work on mobile (and I really should) but what disheartens me is that it seems like this use case is being near ignored by everyone thinking and talking about it.

In my opinion, without a viable solution to touch screen "will-change" is far from a perfect solution.


Just want to point out that you're only mentioning a lack of support in modern IE. Safari also lacks support on both mobile and desktop.


Correct you are. Trying to get the editor to change it. And all points noted and agreed about implementation with touch devices. Although there are quite a few touch events these days available for us. I haven't thought of an efficient way to implement it on touch devices either though...I'll keep thinking.


This just popped up on my Twitter feed sounding a note of caution -

Edit: A response to the concern -


Great article! will-change is simply a paradox.
I once wrote up a little piece about will-change and I came to the point that will-change is a CSS property which can't be used efficiently (especially on mobile devices) without using JS to assign and remove it afterwards (touchstart, touchend,...).
Nevertheless I made some testings on Chrome and documented the facts concerning the browser handling and performance in an article (sorry, it's german. Maybe the translator might help):
It's on the one hand helpful for not recalculating and repainting the whole page, on the other hand hazardous if not tested, that the element on which will-change has been assigned is pushed into a new rendering layer, producing its own stacking context (like an positioned element).
I use will-change whenever it appears useful anyway.


Thank you for this nice introduction! But would you mind to explain in a few words, why the 3D-hack is actually a bad hack? So far I thought it was a nice way to get good performance and delegate various renderings to either the GPU or the CPU. Therefore I kept using it. I am well aware of the battery-on-mobile problem, but it seems that additional al- and delocation of RAM won't be that nice to the battery, either, right? - Anyway, this question is not meant to be stubborn or ignorant, but is intended in the most serious and interested way possible! - Thank you for any on this!


There is a very dark side to this property. May be you want to let your readers know:


I don't think (nor have I stated) that the 3D hack is a bad hack, per say, but it is indeed a hack. When hacks can ultimately be replaced with designated properties, I think we're on course for a better system. Nonetheless, the will-change property comes with its own set of complexities, and I think we have some way to go before properly optimising animations and CPU/GPU usage. It's still a relatively new frontier in front-end development, so I'm sure we'll see changes and improvements constantly!



Because We Like You
Free Ebooks!

Grab SitePoint's top 10 web dev and design ebooks, completely free!

Get the latest in Front-end, once a week, for free.