CSS Animation Performance
Smooth animations need to run at 60fps (frames per second). Poorly optimized CSS animations cause jank (stuttering). Understanding which properties are cheap to animate and how the browser's rendering pipeline works is key to buttery-smooth UI.
Performance Rules
- Only animate transform and opacity - These skip layout and paint, running entirely on the GPU (compositor layer)
- Avoid animating width, height, margin, padding - These trigger expensive layout recalculations
- Avoid animating color, background, box-shadow - These trigger paint but not layout (medium cost)
- will-change: transform - Tells the browser to optimize in advance. Creates a new compositor layer
- Don't overuse will-change - Each will-change layer uses GPU memory. Only add to elements that will actually animate
- contain: layout - Limits layout recalculations to the element's subtree. Isolates expensive changes
- requestAnimationFrame - For JS-driven animations, sync with the browser's render cycle for smooth results
Performance Code
/* ✅ FAST: Only transform + opacity */
.fast-animation {
transition: transform 0.3s ease, opacity 0.3s ease;
}
.fast-animation:hover {
transform: translateY(-8px) scale(1.02);
opacity: 0.9;
}
/* ❌ SLOW: Animating width/height */
.slow-animation:hover {
width: 120%; /* Triggers layout! */
height: 110%; /* Triggers layout! */
margin-top: -10px; /* Triggers layout! */
}
/* ✅ Alternative: Use transform instead */
.fast-alternative:hover {
transform: scale(1.2) translateY(-10px); /* GPU only! */
}
/* will-change optimization */
.animated-card {
will-change: transform; /* Prepare GPU layer */
}
/* Remove when not needed */
.static { will-change: auto; }
/* Contain for performance isolation */
.widget {
contain: layout style paint;
/* Changes inside don't affect outside layout */
}Tip
Use Chrome DevTools' Performance panel to audit animation smoothness. Record while hovering over animated elements and look for frames taking > 16ms (red bars). If you see layout or paint steps for animations, switch those properties to transform and opacity to eliminate them from the pipeline.
Core Web Vitals are Google ranking factors - optimize for all three
Common Mistake
Adding will-change: transform to every animated element as a blanket optimization. Each will-change creates a new GPU layer that consumes VRAM. Adding it to many elements can actually HURT performance by filling GPU memory. Only apply it to elements that animate frequently and noticeably benefit from it.
Practice Task
Compare animation performance: (1) Build a box that animates with top: 0px → top: -20px on hover, open DevTools Performance tab, record 2s, check for layout steps. (2) Rebuild it using transform: translateY(-20px) instead. Record again. (3) Count the layout events - the transform version should show zero.
Quick Quiz
Key Takeaways
- Smooth animations need to run at 60fps (frames per second).
- Only animate transform and opacity - These skip layout and paint, running entirely on the GPU (compositor layer)
- Avoid animating width, height, margin, padding - These trigger expensive layout recalculations
- Avoid animating color, background, box-shadow - These trigger paint but not layout (medium cost)