How do you architect performant, consistent web animations?

Long Answer

A production-ready web animation system balances motion quality with frame stability. The rule is simple: do not drop frames. Avoid layout work during animation, favor compositor-friendly properties, and shape timelines to device budgets.

1. Motion design system and tokens
   Publish a motion spec shared by design and engineering: durations, delays, and easings. Define tokens (xs, sm, md, lg) and standard curves (standard, entrance, exit). Map tokens to use cases: micro-interactions (100–160 ms), navigations (180–280 ms), emphasis (320–400 ms). Provide reduced-motion options.
   
2. Technology choices and capability detection
   Prefer CSS transforms and opacity; they avoid layout and repaint. Use the Web Animations API (WAAPI) for runtime control and scrubbing. Drive orchestration with requestAnimationFrame but mutate transforms only. Feature-detect WAAPI and @keyframes; fall back to class toggles. Respect prefers-reduced-motion by disabling nonessential motion.
   
3. Layout stability and FLIP
   When geometry must change, use FLIP: measure first/last, invert with transforms, then play. Batch reads before writes to avoid forced reflow; coalesce via one rAF tick. Avoid animating width, height, top, left; prefer scale/translate. Use will-change sparingly to hint promotion.
   
4. Performance budgets and scheduling
   Target 60 fps; test at 120 Hz. Stagger timelines; pause offscreen motion with IntersectionObserver. Defer noncritical vectors; suspend when hidden. Throttle physics and pointer sampling on low-end; degrade to simpler transforms during spikes.
   
5. Cross-browser consistency
   Normalize easing with a small named set; snap subpixel values to device pixels to avoid shimmer. Use progressive enhancement: CSS @keyframes first; WAAPI when needed. Validate filter and blend-mode parity; provide vector fallbacks where engines differ.
   
6. Assets: images, SVG, and Lottie
   Compress SVG; pre-rasterize heavy filters. Prefer Lottie for illustrative motion; fall back to spritesheets on very low-end. Ship multiple resolution buckets and cap decoded bytes. Lazy-load animation payloads; prefetch only near-term interactions.
   
7. Input, physics, and real-time
   Model pointer motion with small state machines and velocity tracking. Run springs at a fixed step inside rAF and clamp energy. Debounce wheel/touch gestures and honor native scroll; use ScrollTimeline when replacing it.
   
8. Testing and observability
   Ship a dev HUD showing frame time, long tasks, and layers. Record traces and set budgets. Test motion contracts and assert no layout thrash during key sequences. Capture visual diffs.
   
9. Delivery and governance
   Bundle a small, tree-shaken layer; code-split heavy sequences. Keep tokens in CSS variables. Document do’s and don’ts, ship reusable components with motion defaults, and gate custom timelines through review.
   
   

Done well, animations stay responsive, accessible, and consistent while honoring device limits and compositor constraints.

‍

Table

‍

Common Mistakes

Animating layout properties (width, height, top, left) and blaming devices for jank. Mixing reads and writes per frame, triggering forced reflow. Ignoring prefers-reduced-motion and shipping the same choreography to everyone. Unbounded timelines that run offscreen, wasting battery and GPU. Heavy SVG filters and multiple box-shadows on large layers without prerendering. Relying on JavaScript for every tween instead of CSS/WAAPI, then missing compositor promotion. No FLIP for geometry changes, so lists jump and shimmer. Overusing will-change and creating memory bloat. Inconsistent easing across pages; designers hand-tune timings per component. Blocking main thread with analytics and third-party scripts during hero animations. No tests or perf HUD, so regressions land unnoticed; no pixel snapping, so text and icons shimmer at fractional scales. Skipping code-split for heavy sequences, causing long TTI before the first interaction. Forgetting to pause Lottie when tabs are hidden.

‍

Sample Answers

Junior: I animate transforms and opacity to stay on the compositor and avoid layout. I use CSS @keyframes for most motion, WAAPI only when I need control. I respect prefers-reduced-motion and keep timelines short. For geometry changes I apply FLIP, and I test at 60 fps with a simple HUD.

Mid: I start from motion tokens for durations and easings, then build reusable components with encoded defaults. I schedule with requestAnimationFrame, batch reads before writes, and pause offscreen motion via IntersectionObserver. I normalize easing across browsers, snap pixels to avoid shimmer, and lazy-load Lottie/SVG assets. Visual diffs and traces guard regressions.

Senior: I design a capability-aware system: CSS first, WAAPI for control, and rAF for orchestration. I set budgets, run springs at fixed steps, clamp energy, and downshift effects when frame time spikes. I gate custom timelines through review, code-split heavy sequences, and publish tokens in CSS variables so design and engineering stay in sync.

‍

Evaluation Criteria

Strong answers put frame stability first and show how to keep animation work on the compositor. Look for a motion system with named tokens, a small easing set, and accessibility via prefers-reduced-motion. Candidates explain when to use CSS, WAAPI, and requestAnimationFrame, and how to avoid layout by animating transforms/opacity with FLIP for geometry. Tactics include staggering timelines, pausing offscreen motion, pixel snapping, and lazy-loading assets. Cross-browser consistency comes from progressive enhancement and audits of filters/blends. Testing and observability include a dev HUD, traces, and assertions against layout thrash. Senior candidates quantify budgets (60 fps target, tests at 120 Hz), describe low-end degradations, and outline delivery practices like code-split and review gates for custom timelines. Red flags: animating layout properties, ignoring reduced-motion, JS-heavy tweens, unbounded timelines, excessive will-change, and no governance for tokens/components.

‍

Preparation Tips

Build a small demo that animates cards, a modal, and a list reorder. Implement CSS @keyframes for core motion and WAAPI for scrubbing. Add a dev HUD that shows frame time and long tasks; record a baseline trace. Apply FLIP for the list; verify no forced reflows by batching reads and writes in a single requestAnimationFrame tick. Create motion tokens (durations, easings) in CSS variables and wire components to them. Add prefers-reduced-motion handling and a toggle to preview the experience. Integrate Lottie and an SVG sprite; lazy-load them and pause in background tabs. Use IntersectionObserver to suspend offscreen timelines. Run visual diffs at two DPRs and measure 60/120 Hz devices if available. Load a script during a hero animation to observe main-thread contention, then defer it and compare traces. Document your degradation path for low-end hardware (reduced effects, fewer simultaneous timelines) and capture metrics in the HUD.

‍

Real-world Context

A commerce site reduced jank by moving gallery transitions to transforms/opacity and adopting FLIP for size changes; P95 frame time improved by 35% on mid-range Android. A news portal standardized motion tokens and eased curves; inconsistent timings vanished, and designers shipped new flows without per-page tuning. An education platform paused offscreen animations with IntersectionObserver and suspended Lottie when hidden, cutting background CPU by 60% and extending laptop battery life. A productivity app added pixel snapping and even-scale rules for raster sprites; icon shimmer disappeared on high-DPR screens. A streaming service code-split heavy intro sequences, lazy-loaded SVG filters, and introduced a reduced-motion mode; first interaction time fell and accessibility scores rose. Across teams, a dev HUD and trace budgets caught regressions within hours, not releases, keeping animations smooth at 60 fps while allowing richer effects on powerful devices. A regular audit aligned tokens in code and design, and review gates stopped ad hoc timelines fragmenting the library as features grew.

‍

Key Takeaways

• Animate transforms and opacity; use FLIP for geometry changes.
  
• Encode durations and easings as tokens; respect prefers-reduced-motion.
  
• Stagger timelines, pause offscreen motion, and snap to pixels.
  
• Keep assets light; lazy-load Lottie/SVG and code-split heavy sequences.
  
• Ship a dev HUD, traces, and tests to block regressions.
  
  

Practice Exercise

Scenario: You must ship a responsive landing experience with card grids, a modal, and a reordering list, all animated across desktop and mobile. The site must feel smooth at 60 fps on mid-range phones and respectful of prefers-reduced-motion. A hero illustration uses Lottie; assets must not hurt first interaction.

Tasks:

1. Define motion tokens (durations, easings, distances) in CSS variables and document usage (micro, navigation, emphasis). Add reduced-motion variants.
   
2. Implement card hover and modal entrance with compositor-only properties (transform/opacity). For list reorder, use FLIP with read→invert→play.
   
3. Wire WAAPI for a scrubbed timeline on the hero; drive orchestration with requestAnimationFrame, batching reads before writes.
   
4. Capability-detect and pause offscreen animations via IntersectionObserver; suspend Lottie in hidden tabs; lazy-load its JSON only when near viewport.
   
5. Add pixel snapping and even-scale rules for raster sprites; supply vector fallbacks where filters differ between browsers.
   
6. Ship a dev HUD that records frame time, long tasks, and layers; set an animation budget per page and gate merges on regressions.
   
7. Code-split heavy sequences; prefetch only for imminent interactions; ensure assets keep decoded bytes under a target per screen.
   
8. Create tests that assert zero forced reflows during key sequences and visual diffs at two DPRs and two refresh rates.
   
   

Deliverable: A short runbook with the token table, capability matrix, trace screenshots before/after optimizations, and the budget thresholds used for go/no-go.