Should transitions always have will-change? No. Use will-change only when you have a targeted, high‑cost animation and have already optimized layout and paint costs; overuse harms memory, compositing, and battery life. Understand the tradeoffs before adding it to every transition.
What will-change does and when it matters
The will-change CSS property hints to the browser that an element is likely to change, prompting the rendering engine to set up early optimizations like its own layer. It is not a performance booster by default; it is a last‑resort hint for expensive animations on properties that normally trigger layout or paint (such as top/left or boxShadow) where compositing via transform/opacity would be cheaper. Correct use can make scrolling and transitions smoother on lower‑end devices, but misuse can create many layers, increase memory pressure, and harm frame pacing.
Key definitions
will-change: A CSS property that signals anticipated changes to an element so the browser can optimize ahead of time.- Compositing-only animations: Changes handled mainly on the compositor thread (e.g., transform, opacity) that generally avoid layout and paint work.
- Layer: A separate plane rendered by the compositor; excessive layers degrade memory and battery.
When will-change can help transitions
If your transition animates properties that trigger layout or paint and you cannot easily switch to transform/opacity, a scoped, temporary will-change can reduce jank. Typical scenarios include moving complex vector graphics or animating boxShadow where composite-only substitution isn’t possible. Apply it just before the change (via JavaScript or on the element at the moment the transition starts) and remove it when the transition ends to avoid long‑term layer retention.
Guidelines for helpful use cases
- Target only the specific element animating; avoid applying it broadly to parent containers.
- Prefer animating transform and opacity; reserve
will-changefor the rare cases where those aren’t feasible. - Keep the duration short and the element count low; each flagged element adds layer complexity.
| Property being animated | Compositing-only alternative | Typical need for will-change |
|---|---|---|
| transform / opacity | None needed (already composite-only) | Rarely helpful; usually unnecessary |
| top / left / width / height | Use transform where possible | Consider sparingly if refactor isn’t feasible |
| boxShadow / blur / color | No direct composite-only substitute | Short-term hint may reduce jank on low-end devices |
Risks and downsides of overusing will-change
Treating will-change as a blanket performance fix leads to too many layers, increased memory use, and worse battery life. Browsers may throttle layers when many exist, causing stutter instead of smoothness. It also interacts poorly with mobile GPU limits and can cause visual artifacts like layer clipping or z‑order issues when combined with transforms, opacity, and masks.
Common pitfalls
- Applying
will-changeglobally (e.g., via * or body) rather than scoping it to the animated element. - Forgetting to remove it after the change, leaving an unnecessary layer alive.
- Assuming it makes JavaScript-driven animations faster when the real gains are on the render/composite path.
Best practices for transitions and will-change
Use a performance-first strategy: measure with devtools, prefer transform/opacity, and only add will-change when profiling shows meaningful gains. Implement it as a scoped, temporary hint, and clean it up promptly. Treat it as a conditional tool, not a default property on every transitioning element.
- Profile the animation in the target devices; identify long frames and which stage causes them.
- If the bottleneck is style or layout, consider simplifying the element, reducing repaint areas, or switching to transform/opacity.
- Only if gain remains, add
will-changeto the specific element for the duration of the change. - Remove or set back to auto after the transition to release the layer.
- Test on low‑end hardware and watch memory/compositing metrics, not just FPS in ideal conditions.
Alternatives and complements to will-change
Optimize for transitions using CSS best practices that reduce the need for will-change: promote the element to its own compositor layer via transform: translateZ(0) or contain: paint only when justified, and prefer properties the browser can composite. Use requestAnimationFrame for JS‑driven animations, minimize forced synchronous layouts, and consider the content-visibility and contain-intrinsic-size properties to limit painted regions. Good architecture often removes the need for frequent hints altogether.
Conclusion: strategy over blanket rules
Should transitions always have will-change? No. Apply it selectively, briefly, and only when profiling shows a clear benefit on expensive properties that cannot be improved with compositing-friendly alternatives. Prioritize clean, layer‑light animations and reserve will-change for carefully scoped, performance‑critical cases.