An Introduction to the CSS will-change Property

Originally published at:

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.

Continue reading this article on SitePoint

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. :slight_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.

1 Like

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.

1 Like

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!

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.