CSS animation performance best practices

CSS animations are janky and cause layout thrashing, especially on mobile devices.

Animate only compositor-friendly properties:

/* FAST: Only triggers composite (GPU-accelerated) */
.smooth {
  transition: transform 0.3s ease, opacity 0.3s ease;
}
.smooth:hover {
  transform: translateX(100px) scale(1.1);
  opacity: 0.8;
}

/* SLOW: Triggers layout + paint + composite */
.janky {
  transition: width 0.3s, height 0.3s, top 0.3s, left 0.3s;
}
.janky:hover {
  width: 200px;    /* Triggers layout recalculation */
  left: 100px;     /* Triggers layout recalculation */
}

/* Property cost:
   Layout (expensive): width, height, top, left, margin, padding, font-size
   Paint (moderate): color, background, border-color, box-shadow
   Composite (cheap): transform, opacity, filter
*/

/* Promote to GPU layer for smooth animation */
.will-animate {
  will-change: transform; /* Hint to browser */
  /* Or: transform: translateZ(0); (older trick) */
}

/* Remove will-change when not animating */
.card {
  transition: transform 0.3s;
}
.card:hover {
  will-change: transform;
  transform: scale(1.05);
}

/* Use transform instead of positional changes */
/* BAD */ .slide { left: 0; transition: left 0.3s; }
/* GOOD */ .slide { transform: translateX(0); transition: transform 0.3s; }

/* Reduce paint area */
.animated-element {
  contain: layout paint; /* Isolate repaints */
}

/* Prefer CSS animations over JS for simple motion */
@keyframes fadeIn {
  from { opacity: 0; transform: translateY(20px); }
  to { opacity: 1; transform: translateY(0); }
}
.enter { animation: fadeIn 0.3s ease-out; }

transform and opacity are handled by the GPU compositor without triggering layout or paint. Other properties cause the browser to recalculate layout for potentially thousands of elements.

Web applications with animations or transitions