No, transitions should not always have will-change. Use will-change only when you have a proven performance problem and know which properties will change, because incorrectly applied it can increase memory use and harm rendering performance. For most transitions, the browser’s existing optimizations are sufficient, and careful use of transform and opacity plus efficient rendering is a better default than adding will-change.
When transitions benefit from will-change
will-change tells the browser ahead of time that an element is likely to change, allowing it to set up optimizations such as its own layer and precomputed styles. In carefully measured situations, promoting an element with will-change can make transition animations smoother by reducing layout and paint work during the animation. This is most relevant when a transition animates properties that are expensive to composite or trigger layout, and when the element is already on its own compositor layer.
Supported properties and expected outcomes
Not all CSS properties benefit from will-change, and outcomes vary by engine and device. Commonly cited gains are for transforms and opacity, which are often handled on the compositor. The table below summarizes verified expectations based on typical browser behavior.
| Attribute | Verified Detail | Source Type |
|---|---|---|
transform (translate, scale) |
Often benefits from layer promotion; will-change can reduce main-thread work |
Browser engine specification and measured tests |
opacity |
Typically efficient; gains from will-change are minor unless repaint cost is high |
Browser engine specification and measured tests |
| Layout-triggering properties (width, height, top, left) | Rarely benefit; can cause layout recalcs and slow interactions if overused | Browser engine specification and measured tests |
Risks and downsides of misusing will-change
Applying will-change unnecessarily can backfire. The browser may create extra layers, increasing memory use and potentially causing more frequent layer compositing. In some cases, will-change can trigger forced synchronous layouts or cause the browser to conservatively keep layers in memory longer, which hurts performance on memory-constrained devices.
Common failure modes
- Over-promotion: many elements with
will-changecompeting for limited layer resources - Memory pressure: larger rasterization budgets on mobile and low-memory systems
- Delayed optimization: if applied after the transition has already started, the benefit is lost
Best practices for pairing transitions with will-change
Use a disciplined, measurement-driven approach. Only add will-change when profiling shows a clear bottleneck on the main thread, and remove it when the transition completes. Prefer animating transform and opacity, avoid animating layout-affecting properties, and keep the set of properties in will-change minimal and specific.
Recommended pattern
- Identify the expensive transition via performance profiling (e.g., DevTools Performance panel).
- Apply
will-changeonly to the specific property you are transitioning and only while the transition is expected to occur. - Remove or toggle
will-changeback toautoafter the transition ends (viatransitionendor equivalent).
Browser compatibility and practical considerations
Modern browsers support will-change consistently, but the heuristics for when layer promotion happens differ. Some browsers are more conservative and may ignore will-change if too many elements use it, while others may apply it eagerly at a higher memory cost. Test across target devices and revisit your usage as engines evolve.
Decision checklist for using will-change with transitions
| Decision factor | Guidance |
|---|---|
| Is the transition on transform or opacity? | Likely lower risk and more consistent benefit |
| Have you measured a real main-thread bottleneck? | Use profiling before adding will-change |
| Is the element already on its own layer? | Benefit may be smaller if layer promotion already occurred |
| Are memory-constrained devices a target? | Prefer narrower use of will-change or avoid |
Can you remove will-change after the transition? |
Always prefer removing or toggling back to auto |
Alternatives to will-change for smoother transitions
In many cases you can achieve smooth transitions without will-change. Use transform and opacity for animations, leverage requestAnimationFrame for JS-driven animations, minimize layout work during animations, and ensure repaint areas are small. If you need explicit layer promotion, consider translateZ(0) or translate3d cautiously, but measure because these also carry costs.
Summary and answer to the original question
Transitions should not always have will-change. Apply it selectively, only when profiling shows a benefit, scoped to the specific property being animated, and removed as soon as the transition completes. For the vast majority of transitions—especially those on transform and opacity—relying on browser defaults and efficient animation patterns is the more robust and future-proof approach.