How to Animate Only transform and opacity

This guide is part of Animation & Compositing Performance, within Rendering & CSS Performance. The advice "only animate transform and opacity" is easy to repeat and harder to apply: designs ask for panels that slide, cards that grow, shadows that deepen on hover, accordions that expand and progress bars that fill. Each has a natural implementation with a layout or paint property — left, width, box-shadow, height — and a compositor-friendly alternative that needs a little more thought.

Compositor-only animations keep running smoothly even when the main thread is busy with JavaScript, they do not cause layout shifts, and they do not repaint every frame. This guide shows rewrites for the most common animation patterns and the trade-offs each one introduces.

Rapid Diagnosis

• Enable Paint flashing and trigger the animation; green flashes on every frame mean paint is involved.
• Record a trace; Layout events in each animation frame mean layout properties are animated.
• Open the Animations panel to see each animation's properties and timing.
• Check CLS attribution for elements that move during animations.

Root Cause Analysis

1. Natural property choices. Designers and developers think in positions and sizes.

2. Library defaults. Some animation libraries animate top/left or dimensions by default.

3. Paint-heavy effects. Shadows, gradients and blurs are expensive to repaint every frame.

4. Content reflow requirements. Some designs want surrounding content to move, which needs layout.

Step-by-Step Resolution

1. Replace position animations with translate

.toast { transform: translateY(120%); transition: transform 220ms ease-out; }
.toast.show { transform: translateY(0); }
/* trade-off: the toast's layout box never moves, so it must be positioned
   (fixed or absolute) where it will finally appear. */

2. Replace size animations with scale

.card { transition: transform 160ms ease-out; }
.card:hover { transform: scale(1.03); }
/* Progress bar: scale a full-width bar instead of animating width. */
.progress-fill { transform-origin: left; transform: scaleX(var(--p, 0)); transition: transform 300ms; }
/* trade-off: scaling distorts children (text, borders); keep scale small or
   counter-scale children for larger changes. */

3. Replace shadow animations with opacity

.tile { position: relative; }
.tile::after {
  content: ''; position: absolute; inset: 0; border-radius: inherit;
  box-shadow: 0 12px 28px rgba(0, 0, 0, .18); opacity: 0; transition: opacity 200ms;
}
.tile:hover::after { opacity: 1; }
/* trade-off: an extra pseudo-element per tile adds a little memory; fine for
   dozens of tiles, worth reconsidering for thousands. */

4. Use FLIP for layout changes that must animate

When an element must actually change layout position (reordering a list, expanding a card into a modal), use the FLIP technique: record the First position, apply the Last layout, Invert with a transform so it appears unchanged, then Play by animating the transform to none.

function flip(el, change) {
  const first = el.getBoundingClientRect();
  change();                                             // apply the new layout
  const last = el.getBoundingClientRect();
  const dx = first.left - last.left, dy = first.top - last.top;
  const sx = first.width / last.width, sy = first.height / last.height;
  el.animate([{ transform: `translate(${dx}px, ${dy}px) scale(${sx}, ${sy})` }, { transform: 'none' }],
    { duration: 250, easing: 'ease-out' });
}
// trade-off: two layout reads (one forced) per FLIP; for many elements, read all
// "first" rects together, apply the change once, then read all "last" rects.

Verification

With Paint flashing on, the animated element should flash once at most (when its layer is created), not on every frame. A Performance trace of the animation should show frames without Layout or Paint events, and the Frames track should show no dropped frames under 4x CPU throttling. Run a busy-main-thread test: start the animation and simultaneously run a 300ms task in the console; compositor animations continue smoothly.

Worked Example: A Dashboard's Sidebar Collapse

An analytics dashboard collapsed its sidebar by animating width from 260px to 64px; the main content area, with several charts, re-laid out every frame. On laptops with integrated graphics, the 300ms animation dropped half its frames, and charts redrew during the transition. The team changed the sidebar to a fixed 260px element that translates left by 196px, with the content area's offset switching once at the start of the transition (no animation), and charts resizing once at the end. The animation became smooth, and chart redraws dropped from 18 per collapse to one.

When Layout Animation Is Acceptable

Sometimes a layout animation is the right choice: an accordion where content below must move down, or a list item that grows and pushes siblings. Make it as cheap as possible. Keep the animated subtree small and contained (contain: layout on the container), keep durations short (150–250ms), avoid running heavy JavaScript during the animation, and test on mid-range devices. For accordions, the grid-template-rows: 0fr → 1fr technique animates a single grid track rather than many elements' heights, and interpolate-size: allow-keywords allows animating to height: auto where supported. Accept the cost knowingly rather than by default.

Common Mistakes

• Animating top or left on fixed elements. Still layout every frame; use translate.
• Scaling text-heavy elements a lot. Text looks blurry mid-animation; keep scale changes small.
• Animating width for progress bars. Use scaleX with a left origin.
• FLIP for many elements without batching reads. Thrashing on the measurement step.

Edge Cases

Transforms and stacking contexts. A transform creates a stacking context and a containing block for fixed-position descendants, which can change how children render.

Sub-pixel text rendering. Text on composited layers may render with grayscale antialiasing; usually acceptable.

Hit testing. Transformed elements are hit-tested at their visual position, so buttons work as expected during and after animation.

Reduced motion. Wrap animations in prefers-reduced-motion: no-preference or disable them under reduce.

FAQ

Related

• will-change overuse and layer explosion — layers for these animations.
• Fixing CLS from animating layout properties — the CLS view of the same problem.
• Batching DOM reads and writes — FLIP measurement without thrashing.