CSS width Animation — Why It Breaks 16ms Budgets on Mobile

Every polished web product you've ever used — Stripe's pricing page, Linear's task cards, Apple's product reveals — has one thing in common: motion that feels intentional. That motion isn't magic. It's CSS transitions and animations doing the heavy lifting without a single line of JavaScript. When an element moves, fades, or bounces in a way that feels natural, your brain registers the UI as trustworthy and responsive. Skip the motion and everything feels like a 1997 government website.

The problem most developers run into isn't knowing the syntax — it's knowing WHY the browser behaves the way it does, WHEN to reach for a transition versus a full animation, and HOW to avoid jank that tanks your Lighthouse scores. Animating the wrong CSS property (looking at you, margin) can silently murder your 60fps budget. Animating transform and opacity instead keeps things silky because those two properties skip the expensive layout and paint steps entirely.

By the end of this article you'll know exactly how the browser renders motion, when to use transition versus @keyframes, how to sequence multi-step animations, and the exact gotchas that trip up even experienced developers — so you can ship smooth, performant UI with confidence.

CSS Transitions — Smooth State Changes Without a Single Keyframe

A CSS transition is the simplest form of animation: you tell the browser 'when THIS property changes, don't snap — glide over X seconds.' That's it. No keyframes, no JavaScript, no complexity.

The four pillars of transition are: the property you're watching, the duration of the glide, the timing function (the pace curve), and the delay before it starts. You almost always set these on the element's default state — not the hover or active state — so the transition runs in both directions (in AND out).

The timing function is where most developers stop reading, but it's where all the personality lives. ease starts fast and slows down (great for elements entering the screen). ease-in-out ramps up then back down (great for elements moving across the screen). linear is robotic and usually wrong for UI — it's only really useful for infinite loaders. cubic-bezier() lets you craft a custom curve for that satisfying 'spring' feeling.

The golden rule: only transition transform and opacity for anything that must hit 60fps. Transitioning width, height, margin, or top forces the browser to recalculate layout on every frame — that's expensive and causes jank on lower-end devices.

/* ── Base button styles ──────────────────────────────────────── */
.cta-button {
  display: inline-block;
  padding: 14px 28px;
  background-color: #4f46e5;
  color: #ffffff;
  border: none;
  border-radius: 8px;
  font-size: 1rem;
  font-weight: 600;
  cursor: pointer;

  transition:
    transform 180ms ease-out,
    background-color 180ms ease-out,
    box-shadow 180ms ease-out;
}

.cta-button:hover {
  background-color: #4338ca;
  transform: translateY(-3px);
  box-shadow: 0 8px 20px rgba(79, 70, 229, 0.4);
}

.cta-button:active {
  transform: translateY(0px);
  box-shadow: none;
  transition-duration: 80ms;
}

CSS Keyframe Animations — When You Need a Full Choreography

Transitions only go from A to B. But what if you need A → B → C → back to A, looping forever? That's where @keyframes come in. A keyframe animation defines a named timeline with as many waypoints as you need, then you attach that timeline to any element via animation-name.

Think of @keyframes as writing a script for a play. transition is an actor who improvises between two lines. @keyframes is a full stage direction that says: at the opening curtain do THIS, at the halfway point do THAT, and at the curtain call do THIS OTHER THING.

The animation shorthand packs in eight sub-properties: name, duration, timing-function, delay, iteration-count, direction, fill-mode, and play-state. The ones that trip people up are fill-mode and direction.

fill-mode: forwards means 'hold the final keyframe state after the animation ends.' Without it, your element snaps back to its original style the moment the animation finishes — which looks like a bug but is actually the spec-correct default. animation-direction: alternate makes the animation play forward then backward on odd/even iterations, which is perfect for pulse or breathe effects without needing to mirror your keyframes manually.

@keyframes pulse-ring {
  0% {
    transform: scale(1);
    opacity: 0.75;
  }
  70% {
    transform: scale(1.6);
    opacity: 0;
  }
  100% {
    transform: scale(1.6);
    opacity: 0;
  }
}

.live-indicator {
  position: relative;
  display: inline-flex;
  align-items: center;
  gap: 8px;
}

.live-dot {
  width: 12px;
  height: 12px;
  border-radius: 50%;
  background-color: #22c55e;
}

.live-dot::before {
  content: '';
  position: absolute;
  inset: 0;
  border-radius: 50%;
  background-color: #22c55e;

  animation: pulse-ring 1.5s ease-out 0s infinite;
}

@media (prefers-reduced-motion: reduce) {
  .live-dot::before {
    animation: none;
  }
}

Sequencing and Staggering — Making Multiple Elements Dance Together

A single animated element is fine. A whole list of cards that cascade in one by one feels premium. The technique is called staggering: each element gets the same animation, but with a progressively increasing animation-delay.

The cleanest way to stagger in plain CSS is with the --stagger-index CSS custom property (CSS variable) set inline per element. Your JavaScript or your templating engine sets the index as an inline style attribute. The CSS then reads it and calculates the delay with calc(). This keeps your animation logic in CSS where it belongs, while letting your data layer drive the count.

This pattern is used everywhere: Vercel's dashboard on load, GitHub's contribution graph, Notion's sidebar items. Once you see it, you can't unsee it. The key insight is that the delays are relative to when the animation starts, so if the container has a 200ms entrance delay, all children should account for that in their own delays.

When sequencing is more complex — a loading screen with a logo, then a tagline, then a call-to-action button appearing in order — use explicit delay values rather than a formula. Explicit is clearer and easier to tune during design review.

@keyframes card-enter {
  from {
    opacity: 0;
    transform: translateY(20px);
  }
  to {
    opacity: 1;
    transform: translateY(0);
  }
}

.feature-card {
  opacity: 0;

  animation:
    card-enter
    400ms
    cubic-bezier(0.16, 1, 0.3, 1)
    calc(var(--stagger-index, 0) * 80ms)
    both;
}

@media (prefers-reduced-motion: reduce) {
  .feature-card {
    animation: none;
    opacity: 1;
  }
}

Performance: The Compositor Thread and Why `transform` is King

The browser renders a page in four main stages: Style (calculates styles), Layout (calculates geometry), Paint (fills pixels), and Composite (blits layers together). When you animate a property that triggers Layout or Paint, the browser must recalculate those stages on every frame — that's expensive and causes jank.

Properties like transform and opacity only trigger the Composite stage. They run on the compositor thread, which is separate from the main thread. The main thread handles JavaScript, style calculation, layout, and paint. The compositor thread runs on the GPU and can handle transform and opacity changes at 60fps without blocking the main thread. That's why you should always replace width with transform: scaleX(), top/left with transform: translate(), and margin with transform or padding changes.

will-change is a CSS property that tells the browser to prepare for changes to a property. Using will-change: transform before an animation starts can prevent jank by promoting the element to its own compositor layer. But don't overuse it — each promoted layer consumes GPU memory. Apply it right before the animation starts and remove it after (or use JavaScript to add/remove the class).

/* ── Before: animating width causes layout recalc ── */
.bad-progress {
  width: 0%;
  transition: width 300ms ease-out;
}
.bad-progress.filled {
  width: 100%;
}

/* ── After: use scaleX — no layout, compositor-only ── */
.good-progress {
  overflow: hidden;
  position: relative;   /* contain the scaled child */
  width: 100%;
  height: 4px;
}
.good-progress .bar {
  height: 100%;
  background-color: #22c55e;
  transform-origin: left;
  transform: scaleX(0);
  transition: transform 300ms ease-out;
}
.good-progress.filled .bar {
  transform: scaleX(1);
}

/* ── Use will-change sparingly ── */
.good-progress .bar {
  will-change: transform;
  transition: transform 300ms ease-out;
}
.good-progress.filled .bar {
  will-change: auto;  /* remove after transition ends */
}

/* Alternative: promote via translateZ */
.good-progress .bar {
  transform: translateZ(0);  /* force compositor layer */
  transition: transform 300ms ease-out;
}

Real-World Patterns: Hover Effects, Loaders, and Page Transitions

Now let's combine what you've learned into three production-ready patterns.

Pattern 1: Micro-interaction hover effect — a card that lifts on hover, with a subtle shadow and border color shift. Use transition on transform, box-shadow, border-color. Duration 150ms ease-out for snappy feedback.

Pattern 2: Infinite loading spinner — a @keyframes animation that rotates continuously. Use animation: spin 1s linear infinite; to avoid the eye-strain of easing curves. For accessibility, reduce motion users should see a static spinner (or hide it).

Pattern 3: Page transition — when navigating between views in a SPA, fade out current content and fade in new content. Use @keyframes on a container with animation-fill-mode: both. Coordinate delays with JavaScript to match route change timing.

Key to all patterns: test on real devices, especially low-end Android. A hover animation that's 60fps on an iPhone 15 might be 15fps on a Moto G. Always throttle CPU in DevTools.

/* ── Pattern 1: Card hover lift ──────────────────────────────── */
.card {
  background: #fff;
  border: 1px solid #e2e8f0;
  border-radius: 12px;
  padding: 24px;
  box-shadow: 0 1px 3px rgba(0,0,0,0.08);
  transition:
    transform 150ms ease-out,
    box-shadow 150ms ease-out,
    border-color 150ms ease-out;
}
.card:hover {
  transform: translateY(-4px);
  box-shadow: 0 12px 24px rgba(0,0,0,0.10);
  border-color: #cbd5e1;
}

/* ── Pattern 2: Infinite spinner ─────────────────────────────── */
@keyframes spin {
  to { transform: rotate(360deg); }
}
.spinner {
  width: 24px;
  height: 24px;
  border: 3px solid #e2e8f0;
  border-top-color: #4f46e5;
  border-radius: 50%;
  animation: spin 0.8s linear infinite;
}
@media (prefers-reduced-motion: reduce) {
  .spinner {
    animation: none;
    opacity: 0.5;
  }
}

/* ── Pattern 3: Page fade transition ─────────────────────────── */
@keyframes fade-out {
  from { opacity: 1; }
  to   { opacity: 0; }
}
@keyframes fade-in {
  from { opacity: 0; transform: translateY(8px); }
  to   { opacity: 1; transform: translateY(0); }
}
.page-exit {
  animation: fade-out 200ms ease-out forwards;
}
.page-enter {
  animation: fade-in 400ms ease-out 200ms both;
}