Adaptive Motion: Designing Animation That Respects the Device It Runs On

Animation that looks effortless on a desktop with a discrete GPU can drop frames badly on a mid-range phone. The usual instinct is to blame "mobile performance" in general terms, but the actual causes are specific and mostly avoidable once the underlying mechanism is understood. This is the practice of scaling interface complexity to what a device can realistically render, often called adaptive loading, a term introduced at Chrome Dev Summit 2019 and since documented formally on web.dev. It covers more than animation (serving lower-quality media on slow connections, deferring non-critical scripts), but animation is where the failure mode is most visible, because a stuttering effect is immediately obvious in a way a slightly slower page load isn't.

The cost of ignoring this is concrete: dropped frames read as a broken, low-quality experience even when every other part of a page is fast, and the gap between a developer's own machine and a real visitor's device can be wide enough that the problem never shows up during development at all. It's relevant to any interface with continuous or decorative animation (background effects, idle pulses, anything that runs regardless of user interaction), not just one specific visual technique, and it compounds with a second, related concern: motion that a meaningful share of visitors need to be able to turn off entirely, for reasons that have nothing to do with device performance.

The blur trap

A common pattern: a soft, blurred glow or shape that gently rotates or drifts in the background of a page. It looks subtle and cheap. It is neither, and the reason is more specific than "blur is expensive."

CSS filter: blur() is a convolution filter: computing each output pixel requires sampling many neighboring input pixels, and the cost scales with both the blur radius and the size of the element. That's real cost, but it's a one-time cost if the element never changes. The actual trap appears when that blurred element also animates a property like transform.

Animating transform causes the browser to promote the element to its own compositor layer. This is normally the correct thing to want, since compositor-layer animation is usually cheap and smooth. For a blurred layer specifically, it backfires: Chrome's own engineering team has documented that a promoted, blurred layer gets re-rasterized on every single frame, even when the blur radius itself isn't changing at all. The browser isn't reusing a cached blurred image; it recomputes the convolution from scratch, every frame, for as long as the animation runs. For one element this might be invisible. For several full-viewport blurred shapes animating simultaneously, it can saturate a mobile GPU's frame budget on its own, without anything else on the page being at fault.

Chrome's documented team even tried the obvious workaround, pre-blurring several fixed radii and cross-fading between them with opacity, and it still didn't fully solve the problem, because each promoted texture still needed re-blurring per frame. The fix that actually worked: promote the parent wrapper of the blurred element to its own layer, not the blurred element itself. That lets the browser rasterize the blur once into the parent's texture and reuse it, instead of recomputing it on every composite.

The practical takeaways:

Keep blur radii modest. Under roughly 20px reads as smooth in practice; larger radii cost more and are more likely to be visually unnecessary anyway.
Avoid animating a property that triggers layer promotion (transform, opacity in some engines) directly on a blurred element. Animate a property that doesn't force re-rasterization, or restructure so the promoted layer is the parent, not the blurred child.
Be more conservative with blur on mobile specifically. The GPU headroom that makes desktop animation forgiving usually doesn't exist there.

Respecting `prefers-reduced-motion`

prefers-reduced-motion is a CSS media feature that reflects an operating-system-level accessibility setting, not a browser preference. A user configures it once in their system settings, and every site that respects it benefits automatically. It maps directly to a formal accessibility requirement: WCAG 2.3.3, "Animation from Interactions" (Level AAA), which requires that motion triggered by user interaction be possible to disable, unless the motion is essential to the interface's function.

This exists because animation is not just an aesthetic preference for some users. It can trigger real, physical symptoms for people with vestibular disorders: vertigo, nausea, disorientation. A media query that many developers treat as a nice-to-have is, for a meaningful number of visitors, the difference between being able to use a page comfortably and not.

Respecting it well means more than a blanket animation: none. The generally recommended approach:

.decorative-motion {
  animation: drift 12s ease-in-out infinite;
}
 
@media (prefers-reduced-motion: reduce) {
  .decorative-motion {
    animation: none;
  }
}

Purely decorative motion (background effects, idle pulses, anything not carrying information) should be removed entirely under this setting. Motion that communicates something, like a loading spinner indicating progress, should usually stay, since removing it removes real information. Where some motion is unavoidable, keeping it brief (a few seconds at most) and swapping a jarring effect for a simple cross-fade is a reasonable middle ground.

There is also a newer HTTP Client Hint, Sec-CH-Prefers-Reduced-Motion, that lets a server read this preference and adjust server-rendered output directly, rather than relying solely on client-side CSS or JavaScript to react to it after the fact.

Detecting device capability honestly

Beyond respecting an explicit user preference, it's tempting to detect a device's raw capability and scale animation complexity automatically. A few signals exist, but each comes with real limitations worth knowing before depending on them:

navigator.hardwareConcurrency reports logical CPU core count and is broadly supported, but browsers increasingly clamp or round the reported value for anti-fingerprinting reasons. Treat it as an approximate signal, not an exact one.
navigator.deviceMemory (the Device Memory API) is Chromium-only: it has never shipped in Safari or Firefox. Its value is also deliberately imprecise (rounded to the nearest power of two and clamped), for the same fingerprinting-mitigation reason. It cannot be relied on as a cross-browser signal.
The Network Information API (navigator.connection) is a WICG draft specification, and MDN explicitly flags it as not part of the Baseline set of broadly-supported web features, in large part because Safari has never implemented it. It should be treated as opportunistic progressive enhancement for Chromium/Android specifically, always behind a feature check, never as a dependency the interface requires to function correctly.

A viewport-width check (effectively, "is this a small-screen device") is a blunter signal than any of the above, but it has the advantage of working identically everywhere, with no vendor-specific gaps. Combining it with hardwareConcurrency as a secondary, non-authoritative refinement is a reasonable, honest middle ground: treat the result as "probably lower-powered," gate a cheaper variant of an effect behind it, and never gate correctness or core functionality on it.

A no-JavaScript adjacent technique

Not every adaptive-loading win requires capability detection at all. content-visibility: auto, a CSS property that reached Baseline "newly available" status in September 2024, tells the browser to skip layout and rendering work for elements that are off-screen, resuming it automatically as they approach the viewport. For a long page with many below-the-fold sections, this can meaningfully cut initial rendering cost with a single declarative CSS rule and no JavaScript branching at all.

Scaling instead of switching off

The pattern worth internalizing across all of this: adaptive loading is about scaling an effect, not simply turning it off for anyone who might struggle with it. A background animation can keep its resting visual (the color, the composition) while dropping the specific property that's expensive to animate continuously. One real example of this: a page with several animated, blurred background shapes kept its full visual treatment on capable hardware, but on a detected low-power device switched from animating both position and opacity to animating opacity alone, removing exactly the transform-driven layer-promotion cost described above, while the shapes themselves stayed visually present rather than disappearing. The same page respected prefers-reduced-motion independently of that device check, dropping to a static resting state regardless of hardware.