The assumption that a richly animated site must be a slow site comes from how animation is usually added: late, on top of a finished page, by whichever library was nearest.
Budget first, design second
We set a bundle and vitals budget before design begins and enforce it in CI. A build that exceeds it fails. That single constraint changes every downstream decision for the better.
- Server components by default; client components only where interaction demands it
- Animation confined to transform, opacity, filter and clip-path
- Heavy visual work dynamically imported and mounted below the fold
- Expensive pointer and 3D interactions removed entirely on touch devices
Animate the compositor, not the layout
Layout-bound properties force the browser to recalculate geometry on every frame. Compositor-friendly properties do not. This one rule accounts for most of the difference between motion that feels premium and motion that stutters.
/* Avoid: forces layout on every frame */
.card:hover { top: -8px; height: 420px; }
/* Prefer: composited, GPU-friendly */
.card { transition: transform 300ms cubic-bezier(0.16, 1, 0.3, 1); }
.card:hover { transform: translate3d(0, -8px, 0); }Reduced motion is not a downgrade
Respecting prefers-reduced-motion does not mean removing all feedback. It means replacing distance and parallax with opacity and colour, so the interface still communicates state without provoking discomfort.
Designed properly, the reduced-motion experience should feel like a deliberate variant of the same system — not a stripped-back fallback.