CSS will-change Property

The will-change property is a performance hint that lets authors tell the browser which aspects of an element are likely to change soon so the rendering engine can prepare optimizations in advance. By advertising upcoming changes, the browser can make decisions such as promoting the element to its own compositing layer, precomputing intermediate states, or adjusting rasterization strategies to reduce frame drops and layout thrashing when the change actually happens. Crucially, it is only a hint — browsers retain freedom to ignore it if applying the hint would be more expensive than beneficial in a given context.

Using will-change affects the browser’s internal work pipeline (layout, painting, compositing, rasterization) rather than changing visual behavior directly. For example, elements that are composited can be animated more smoothly because the compositor can move pixels without forcing a full repaint on each frame; this is why it’s frequently used ahead of changes to properties like transform, opacity, or filter. However, those optimizations come with trade-offs: creating extra layers increases memory use and may increase the cost of certain operations (for example, when layers need to be rasterized at different resolutions), so indiscriminate or long-lived use of the hint can worsen overall performance rather than improve it.

Best practice is to use will-change sparingly and only for the brief period surrounding the change. Add the hint just before you trigger a transition or animation and remove it when the operation finishes; this limits the time the browser has to carry extra resource overhead. In many cases, structural techniques such as limiting repaint scope with the contain property or choosing properties that are naturally handled on the compositor can be preferable. Also consider pairing the hint with animation strategies (for example, using transition or animation that target compositable properties) so the browser can take advantage of hardware-accelerated compositing without unnecessary painting work.

Finally, remember that will-change is an optimization tool, not a fix for layout or scripting inefficiencies. Profiling and testing remain essential: measure frame rates and memory usage with and without the hint, and prefer design patterns that minimize forced synchronous layouts and costly paint operations in the first place.