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. 