The will‑change Property in CSS

As designs for web apps and websites have become increasingly complex and animated, browsers are having to work not only harder, but smarter, too.

With the CSS will‑change property you can give a helping hand to rendering engines by signalling areas of the screen that might be expected to change. This is helpful if you notice any performance issues — but it's not quite as straightforward as it seems.

What is will‑change?

First up, let's go over what will‑change actually is, and is intended to do.

Browsers are obsessed with optimisation. From the moment the first bytes come back from a request, the browser will be trying to figure out how best to render the elements in the front end of the page or in the view with the least amount of power possible, as quickly as possible, and in the best way possible for any animations or interactivity. This includes taking media queries into account.

As a side note: this rigorous optimisation is also why mobile‑first responsive development is more performant than desktop‑first. Smaller‑screened (and often lower‑powered) devices only need to optimise for styles relevant to their screen size when that's where you start your styling declarations. With desktop‑first, the visiting device has to work its way through all the styles (from larger ‑ irrelevant ‑ screen styles down) before it can render the page.

Back to the topic at hand: with will‑change, you can alert the browser to any heavy work that might seriously affect performance by letting it know how a particular element is going to change. This can give the browser the chance to get optimisations ready before it needs them, potentially freeing up performance and resources for the rest of the page.

Here are the values that will‑change can accept — heads up, some of them seem a little vague at first glance:

will‑change: auto;

This is essentially the default setting and doesn't really help the browser out. It tells the browser to work with and optimise the element the way it was already going to.

will‑change: scroll‑position;

This tells the browser that it should be ready for the element to change its scroll position. The browser might see this as meaning it should optimise for content that isn't in the initial viewport.

will‑change: contents;

And this keyword tells the browser to expect some sort of change to the contents of the element. The browser might interpret this to mean that it shouldn't prepare the cache for content inside this element.

Thankfully, you can also specify specific properties by using their names. For instance: will‑change: transform; So, that seems pretty handy! Right? Well…

The Complications

Unfortunately, will‑change isn't a silver bullet for you to include in all of your web apps or sites in order to boost those Core Web Vital scores.

Distinctly because it changes how the browser approaches rendering and optimisations, it can cause more problems than it solves if you're using it unnecessarily. It's not intended as an optimisation for developers to make in the same way as minifying your JS or CSS, or specifying your caching rules via .htaccess. Instead, it's intended to be used as a last resort if you're noticing specific performance issues within specific elements.

It is recommended that you use it very sparingly, even to the extent where best practice is suggested to be toggling the will‑change property on and off, as and when you're about to change the property you're giving the browser a heads‑up about.

If you use it on too many elements, you might even end up with a less performant page, frustratingly. This is because browsers are fairly complicated things, and the rendering engines they use take a lot of things into account when figuring out how to approach optimisations. If you start getting involved and telling it how it should be working instead, you run the risk of the browser chewing up a bunch of the resources available to it (the classic Chrome experience) and affecting the performance of your web app or page.

The final thing to be aware of when you're working with properties that you're affecting with will‑change is the stacking context. I've already written about stacking contexts and z‑index in a past post, and how it can be a confusing, murky and frustrating mess when working with complex animations or layouts. So, throwing this extra spanner in the works might be a bit of a deal‑breaker.

Essentially, when used with properties like opacity, will‑change can create a new stacking context as the browser tries to plan out its optimisations. If you're seeing some strange and unexpected front‑end behaviour when it comes to z‑index shenanigans, this property could be to blame.

The Wrap‑Up

will‑change can be a useful property when you know exactly what's wrong, and are already experiencing issues. Using it, you can help guide the browser and end up with a more performant, less resource‑heavy, faster page that's better for your users to work with.

However, overusing it will cause your web app or site to run slower. It will hurt performance if you try to use it where there isn't a specific problem, and it might be best to rework your code or design if you find yourself using it as a crutch often.