What does the CSS `will-change` property do, and why can putting `will-change: transform` on many elements make a page slower?
answer
- a hint, not an effect
- preparation costs memory
- layers scale with area and count
- permanent hint stops being a hint
- engines already promote running animations
basics
~20 swill-change tells the browser which properties are about to change so it can prepare, usually by giving the element its own composited layer. Each layer costs memory, so applying it broadly wastes resources and slows the page.
solid answer
~50 s`will-change` is a hint, not an effect: it declares that a property such as `transform` or `opacity` is about to change so the engine can do preparatory work up front — typically promoting the element to its own composited layer so the first animated frame does not stutter. The cost is that a layer is real memory, roughly proportional to the element's pixel area, and hundreds of them will exhaust graphics memory on a mid-range phone long before they help. The specification is explicit that you should not apply it to too many elements and should remove it once the element stops changing. It also has side effects — declaring it for `transform`, `opacity` or `filter` makes the engine establish a stacking context immediately, which can change how overlapping elements paint. In practice I use it narrowly, for interactions the engine cannot predict, and let it apply only while the interaction is live.
go deeper
Know that will-change is only a hint that something is about to change, and that it is not a general performance switch to sprinkle on elements.
Explain the mechanism — it lets the engine prepare, usually by promoting the element to its own layer — and that each layer holds real memory proportional to the element's area.
Demonstrate operating judgment: name the symptom that justifies it, scope it to a live interaction rather than a stylesheet, and mention the stacking-context and text-rendering side effects it drags along.
Own the policy — when a codebase should ban blanket will-change rules, how you review the ones that exist, and how you keep memory-hungry hints out of shared components that render hundreds of times.
## A hint about the future, not a command `will-change` does not animate anything and does not change how a property renders. It is a declaration of intent: *I am about to change this property, so get ready*. The browser is free to act on it, ignore it, or drop it under memory pressure. Accepted values are property names — `will-change: transform`, `will-change: opacity`, `will-change: transform, opacity` — plus two special keywords, `scroll-position` (this element's scroll offset is about to change) and `contents` (its contents change often enough that caching them is pointless), and `auto`, which is the initial value meaning "no hint". What the engine typically does with a `transform` or `opacity` hint is promote the element to its own composited layer ahead of time, so that when the change arrives the surface is already rastered and the first frame is just a re-draw. ## Why it backfires when over-applied **Layers are memory.** A composited layer holds rastered pixels; its cost scales with the element's area, and it is paid for as long as the layer exists. A stylesheet that puts `will-change: transform` on every card in a long list creates hundreds of them at once. On a mid-range phone that can mean a large graphics-memory footprint for elements that will never animate, and the memory the browser needed for the *one* element you actually animate is now contended. **A permanent hint is not a hint.** The whole value of `will-change` is warning about an imminent change. Declaring it in a stylesheet on a static element tells the engine the change is always imminent, so the preparatory work is never released. The specification says as much: do not apply it to too many elements, and remove it when the element stops changing. **It is usually unnecessary for CSS animations.** Engines already promote elements that are running a `transform` or `opacity` animation or transition — they can see the animation and know what is coming. Adding `will-change` on top of a declarative animation buys little. It earns its place for changes the engine *cannot* see coming: a drag that starts on pointer-down, a menu whose first frame must be instant, an element whose transform is driven by script. **Side effects come with it.** Declaring `will-change` for a property whose non-initial value would create a stacking context — `transform`, `opacity`, `filter` — makes the engine create that stacking context immediately, even at the initial value. That can change how overlapping elements paint and how positioned descendants resolve. It can also change text rendering on some platforms, because promoted layers may lose subpixel antialiasing, which shows up as text that looks slightly lighter or blurrier once the hint is applied. ## Using it well Scope it to the moment, not the stylesheet: ```css /* the hint lives on a state, not on the element forever */ .drawer { transform: translateX(-100%); transition: transform 250ms ease; } .drawer-host:hover .drawer, .drawer.is-dragging { will-change: transform; } ``` Applying the hint on a hover of an *ancestor*, or on a class that exists only while a drag is in flight, gives the engine its warning shortly before the change and lets it release the resources afterwards. The rule of thumb is a handful of elements at a time — the currently open panel, the item under the pointer — never a blanket selector. ## The legacy version Before `will-change` existed, people forced layer promotion with `transform: translateZ(0)` or `backface-visibility: hidden` — declarations chosen for their side effect rather than their meaning. They still work, in the sense that they still create a 3D context, but they are the wrong thing to write today: they lie about intent, they cannot be expressed for `opacity`, and they cannot be released. Recognising the hack in an old codebase and replacing it with a scoped `will-change` (or with nothing at all) is a reasonable answer to "what would you change here". ## The honest framing `will-change` is a targeted fix for a specific symptom: a visible hitch on the *first* frame of an interaction, because the engine had to raster a surface at the moment the user acted. If you cannot describe the symptom, you do not need the property. Reaching for it as a general speed-up is the most common way it ends up costing more than it saves — and confirming that it helped is a measurement question, not a styling one.
- If an element already runs a CSS transform animation, does adding will-change to it help?Usually not. The engine can see a declarative animation and prepares for it on its own, so the hint mostly duplicates work that already happens. Reserve it for changes that arrive unpredictably — a drag, a script-driven transform, a panel that must move on the very first frame after a click.
- What is wrong with `transform: translateZ(0)` as a way to force layer promotion?It is a side effect masquerading as intent: it says the element is displaced in 3D when you meant "prepare for change". It cannot express an opacity hint, it cannot be released without removing a real transform, and it leaves a reader guessing. `will-change` states the intent directly and can be scoped to the interaction.
- How would you decide whether a will-change declaration in an existing stylesheet is worth keeping?Ask what symptom it was added for. If nobody can name a hitch it fixed, remove it and see whether anything regresses. If it sits on a broad selector, narrow it to the element that actually animates and to a state class that exists only during the interaction, then confirm the improvement rather than assuming it.
It is like warming up a car before a trip: sensible for the one you are about to drive, ruinous if you idle the whole fleet all day.
saying these in an interview costs you the question
- Says will-change makes animations run on the GPU and is always faster
- Applies it globally in a stylesheet as a blanket optimisation
- Thinks a layer is free once created
- Believes will-change animates the property by itself
- Says it has no side effects on painting or stacking