Smooth CSS Keyframe Animations Without a Library

Smooth CSS animation is not about easing curves or clever keyframes. It is about which properties the browser can hand entirely to the compositor.

A browser renders a frame in stages: style, layout, paint, composite. Animating a property that forces an earlier stage means redoing that stage sixty times a second on the main thread, competing with your JavaScript. Animating a property handled at the last stage means the compositor can run it on its own, frequently on the GPU, even while the main thread is busy.

In practice, exactly two properties composite cleanly across every current engine:

• transform — translate, scale, rotate, skew
• opacity

Everything else has a cost. Animating width, height, top, left, margin or padding triggers layout, the most expensive stage, because the browser must recompute the geometry of the element and potentially everything around it. Animating background-color, box-shadow, border-radius or color triggers paint, which is cheaper than layout but still main-thread work proportional to the pixel area involved.

This is why the same visual effect can be smooth or janky depending purely on how it is expressed. Sliding a panel in with left: -300px → 0 and with transform: translateX(-300px) → none look identical and cost radically different amounts.

Most expensive animations have a direct transform equivalent.

Movement. Replace top, left, right, bottom and margin offsets with translate:

```css /* expensive: triggers layout on every frame */ @keyframes slide-in-bad { from { left: -320px; } to { left: 0; } }

/* cheap: composited */ @keyframes slide-in { from { transform: translateX(-320px); } to { transform: translateX(0); } } ```

Size. Replace width and height with scale. The caveat is real: scaling an element scales its text and borders too, so this substitution suits cards, overlays and shapes rather than text containers that must stay crisp.

Appearance and disappearance. Animate opacity, never display. display is not animatable and switching it mid-animation cancels the effect. The correct pattern pairs opacity with visibility, which is animatable in the sense that it snaps at the end of the transition rather than the start:

.panel {
  opacity: 0;
  visibility: hidden;
  transition: opacity 200ms ease, visibility 0s linear 200ms;
}
.panel.is-open {
  opacity: 1;
  visibility: visible;
  transition: opacity 200ms ease, visibility 0s;
}

Height, honestly. Animating an element from zero to its natural height is the one common case with no clean transform equivalent, because the final height is unknown. Modern browsers support interpolating to height: auto with interpolate-size: allow-keywords, and grid-template-rows: 0fr → 1fr is a widely supported alternative. Both still cost layout; the honest position is that this animation is expensive and should be short.

will-change: transform tells the browser to promote an element to its own compositing layer ahead of time, so the first frame of an animation does not stall while that happens.

It is genuinely useful and routinely misused.

Each promoted layer consumes GPU memory proportional to its rasterised size. A handful of promoted elements is unremarkable. Applying will-change to a long list, or leaving it set permanently in a stylesheet, can exhaust memory on mobile devices and produce exactly the stutter it was meant to prevent.

Two rules keep it safe:

1. Set it close to the moment it is needed and remove it afterwards. Adding it on hover or focus, or via a class applied just before the animation begins, is the intended use.
2. Never apply it to a large number of elements at once.

.card { transition: transform 180ms ease; }
.card:hover { will-change: transform; transform: translateY(-4px); }

The older transform: translateZ(0) and backface-visibility: hidden hacks achieve promotion as a side effect. They still work, but they say nothing about intent and cannot be removed as cleanly. will-change is the property that exists for this and is the one to reach for.

Once an animation is cheap, what remains is whether it feels right, and that is mostly two numbers.

Duration. Interface motion lives in a narrow band. Under roughly 100ms a transition is perceived as an abrupt change rather than a movement. Over roughly 400ms it begins to feel as though the interface is waiting on itself. Useful defaults: 120–180ms for small state changes such as hover and focus, 200–300ms for entrances and exits, and 300–400ms reserved for large surfaces crossing a substantial distance.

Easing. Linear motion looks mechanical because almost nothing in the physical world moves at a constant speed. The defaults encode intent:

• ease-out — fast at the start, settling at the end. Correct for things entering, because the element arrives promptly and comes to rest gently.
• ease-in — slow at the start, accelerating away. Correct for things leaving.
• ease-in-out — for movement that both begins and ends on screen.

A custom cubic-bézier is worth it only when you want a specific character. cubic-bezier(0.16, 1, 0.3, 1) produces a decisive, slightly-overshooting settle that suits panels and modals:

.panel { transition: transform 260ms cubic-bezier(0.16, 1, 0.3, 1); }

Distance should influence duration. An element crossing 600px in the same 180ms as one moving 4px will look like it teleported. Scaling duration gently with distance — not linearly, but noticeably — is what separates considered motion from uniform motion.

Some people experience nausea, dizziness or migraine from interface motion. Vestibular disorders are common, and the operating system already exposes the preference. Honouring it is a correctness requirement, not a nicety.

The wrong implementation removes all animation, which frequently breaks interfaces that rely on a transition to communicate that something changed. The better approach is to replace movement with a fade and shorten durations, keeping the feedback while removing the travel:

@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

That global reset is the widely used safety net, and it is a reasonable floor. Where an animation carries meaning, prefer a targeted rule that keeps an opacity change while dropping the transform:

@media (prefers-reduced-motion: reduce) {
  .panel { transition: opacity 120ms ease; transform: none; }
}

Large parallax effects, auto-playing carousels and anything that moves across a significant portion of the viewport are the highest-risk patterns and should be disabled outright under this query.

When an animation stutters, guessing which property is responsible is slower than measuring.

Open the browser's performance profiler, record while the animation runs, and look at the frame timeline. Long purple Layout bars mean a geometry property is being animated — find it and convert it to a transform. Long green Paint bars mean a paint-triggering property such as box-shadow or background-color is animating over a large area. Frames that are mostly yellow Scripting mean the animation is fine and your JavaScript is starving the main thread; in that case moving the animation to the compositor with transform will keep it smooth even while the script runs.

Chromium's rendering panel adds two checkboxes worth knowing. Paint flashing highlights repainted regions in green — a well-built animation should show almost none. Layer borders draws the boundaries of compositing layers, which makes it immediately obvious whether promotion is happening and whether far too many layers exist.

The most common single finding: an animation that is correctly written with transforms but sits inside a container whose box-shadow or filter is also transitioning, forcing a repaint of the whole area every frame regardless.

The CSS animation generator builds keyframes using transform and opacity by default, which is the distinction this article is about. For the surfaces being animated, the gradient studio and glassmorphism generator produce the backgrounds.