Rachel Nabors: Now it's time that we have a talk about will-change. I've heard will-change come up a bit in the chat room. It's important for us to cover this. Will-change, ostensibly, is a CSS property that lets us give the browser a little heads up as to what other CSS properties we might possibly be animating in the future.
This lets the browser go, aha, and it goes out there and makes some little, I don't know, tweaks, to how it's going to be handling those properties, so that it can give us the best performance. Used to be that we would do this using something called the hardware acceleration.
Unless you were putting everything on the GPU, in which case it could get pretty crowded in there and your phone might crash. So this is why people would add this translateZ thing, it's kind of a magical number. TranslateZ(0) is actually a way of saying, I'm going to transform this into 3D plane, but you don't actually.
So it was a way of tricking the browser into kicking things over to the GPU. And sometimes, if it was used willy-nilly, it could actually cause more harm than good. So if you're thinking about using something like this, you probably shouldn't be. Magic fixes do not age well.
When you have people coming in to maintain your code, they'll be like, what is this, I better not touch it, it might break something. So you can end up carrying all these not necessarily performant magical fixes with you for a long time. It creates technical debt. So this is not how we like to do things.
Hacks are not future friendly, they just make you think that you're getting a good deal. So Chrome introduced will-change in hopes that they could prevent people from doing this sort of thing. The idea is that will-change, what you do here, you're supposed to use will-change just before you're going to animate something.
This creates an interesting set of problems. You think, well all right, I'm going to be using a transform on this thing in the future sometime, so I'll just will-change all the transforms. Well, you could do that. But it would be even more performant if you could do a just in time will-change on that transform.
Say when somebody is hovering over something that if they click it, it will be transformed, then you could add the will-change just to that thing or maybe only if that thing is in view. So if you're using will-change, you'll also probably, to use it most effectively, going to be doing a lot of event-sniffing to figure out when people are getting close to making that change.
It sounds a lot like doing the browser's work for it. And that is one of the complaints I have heard. That this is really just something that supports Chrome's, how shall I put this, Chrome's lack of focus on animation in its development processes. Because there are browsers that claim that they do not need will-change, Edge is one of them.
I have heard an Edge developer on the Internet say that Edge will never have will-change, because will-change is not necessary for Edge's performance pipeline. So that gets into this thing, different browsers have different rendering processes, and some of them might not need this at all. So what is will-change but a magic number for Chrome?
Rachel Nabors: So if you are going to use will-change, which I would say is the more sanctioned version of the translateZ hack, as at least you're letting the browser decide when it wants to put things on the GPU or whatever it's going to do. So don't slap it on everything.
If you slap will-change on everything, you are optimizing nothing. And let's take a look at this browser spread. At Caniuse.com, you'll see that will-change is rather well supported by Firefox, Chrome, Safari, and Opera even, my God. But, iOS Safari, Opera Mini and Internet Explorer totally not buying into the will-change movement.
And I've all ready given you the reasons for why those browsers might be recalcitrant about adopting will-change.