Detailed explanation
The CSS `will-change` property tells the browser that an element is likely to change in a particular way soon. For example, `.card { will-change: transform; }` hints that the card’s transform will change. It does not start an animation, change the property itself, or guarantee faster rendering. Instead, it gives the browser an opportunity to prepare optimisations before an interaction begins, potentially reducing the initial hitch in an animation. It is most useful when profiling reveals a rendering problem, rather than as a default rule for every interactive element.
To understand its effect, consider the rendering pipeline: style calculation, layout, paint, and compositing. Changes to dimensions such as width can require layout and repainting, while transform and opacity animations can often be handled during compositing without repeating layout or paint on every frame. With a suitable `will-change` hint, the browser may create a separate compositing layer and prepare its rasterised content ahead of time. However, layer promotion is a browser decision, not a promise made by the CSS specification. Also, `will-change: width` does not make width animations bypass layout.
These preparations have costs. Extra layers and backing surfaces consume memory, and creating, rasterising, uploading, and managing them adds work. Keeping hints on many elements can therefore make rendering slower, especially on memory-constrained devices. A hint can also affect visual behaviour: for properties that create a stacking context, such as transform or opacity, `will-change` creates that context in advance. This can change how overlapping elements are ordered, even before an animation starts, so it is not always a visually neutral performance switch.
In practice, apply the hint to a small number of elements shortly before a known change, allowing some preparation time, and reset it to `auto` or remove the temporary class after the interaction finishes. Adding it in the same JavaScript task as the animation may provide little advance notice. A permanent hover-card rule is simple but keeps preparations active unnecessarily. Interviewers generally expect you to explain both the possible compositing benefit and its resource cost, then mention validating the result with browser performance tools.
Key points to remember
- `will-change` is an advance hint, not an animation trigger or performance guarantee.
- Transform and opacity hints may enable preparation for compositor-driven animations.
- It does not eliminate layout or paint work inherently required by a property.
- Excessive layer preparation consumes memory and can reduce rendering performance.
- Apply targeted, temporary hints and verify their effect with performance profiling.
Common mistakes candidates make
- Applying `will-change` globally or permanently to every potentially animated element.
- Assuming it guarantees GPU acceleration or makes layout-changing animations compositor-only.
- Adding the hint simultaneously with the animation and expecting preparation to be completed beforehand.
Likely follow-up questions
Why are transform and opacity commonly recommended for animations?
They can often be updated during compositing without recalculating layout or repainting content on every frame. Actual behaviour depends on the element and browser, so confirm it with profiling.
When should you add and remove will-change?
Add it when an upcoming animation becomes predictable, such as during an earlier interaction stage, rather than at the exact moment it starts. Remove the temporary declaration or reset it to `auto` when the animation ends or is cancelled, unless another change is imminent.
How would you check whether will-change actually helps?
Compare recordings with and without the hint using browser DevTools, looking at frame timing, paint activity, and compositing layers. Test on representative lower-powered devices as well, because extra memory use can offset improvements seen on a desktop.
Interview tip: Explain the rendering pipeline briefly, use transform as your example, and finish with the memory trade-off and temporary-use recommendation.