will-change: performance optimization with caveats

Animations are janky or cause layout repaints. Adding will-change is meant to fix this but is sometimes overused, causing performance regressions instead.

Use will-change judiciously, only on elements that are about to be animated, and remove it after the animation:

/* Apply just before animation starts (e.g., via JS on hover) */
.card {
  transition: transform 0.3s ease;
}

.card:hover {
  will-change: transform; /* hints browser to promote to composite layer */
  transform: scale(1.05);
}

/* Remove after animation via JS for long-lived elements */
element.addEventListener('transitionend', () => {
  element.style.willChange = 'auto';
});

/* Never do this on many elements */
/* * { will-change: transform; } -- defeats the purpose */

/* For known persistent animations */
.spinner {
  will-change: transform; /* always spinning, OK to keep permanently */
  animation: spin 1s linear infinite;
}

will-change tells the browser to promote an element to its own compositor layer before the animation starts, avoiding jank from promotion during the animation. However, each promoted layer consumes GPU memory — overuse wastes memory and can cause slowdowns.

Performance optimization of CSS animations and transitions.