Motion With Intent: Animation That Doesn't Wreck Performance

Motion is the fastest way to make a site feel expensive — and the fastest way to make it feel broken. The difference is intent. Animation bolted on at the end fights the layout, drops frames, and punishes anyone on a mid-range phone. Animation planned with the build disappears into the experience. Here's how we keep motion fast.

Animate the cheap properties

Browsers render some changes almost for free and others at great cost. We animate transform and opacity — the GPU-friendly pair — and avoid layout properties like width, top, or margin that force the browser to recalculate the page. A transform-only animation runs at 60fps on hardware where a layout-thrashing one stutters.

Choreograph with scroll, don't fight it

Scroll is the primary interaction on most sites, so we treat it as a timeline. Pinned sections, scrubbed reveals, and velocity-reactive effects are driven by a single smooth-scroll loop rather than a pile of competing listeners. One source of truth means no jank when two effects want the same frame.

• One RAF loop for scroll and animation
• Transforms and opacity only in the hot path
• Lazy-load heavy WebGL behind the fold

If the animation can't survive a three-year-old Android, it isn't done.

Make reduced-motion a first-class path

Every motion we ship has a reduced-motion branch that degrades to a static, fully-readable layout — not an afterthought, a designed state. It's better for accessibility, and it's a useful forcing function: if the page only makes sense with the animation, the content underneath is too thin.

Hold a performance budget

We set Lighthouse and Core Web Vitals targets at the start and treat them like any other acceptance criterion. Motion is negotiable; speed isn't. The result is sites that feel alive and still load instantly — because the two were never in opposition, only in need of discipline.