How do you keep animation from hurting performance on a weak device?

Animation stays smooth on weak hardware when you design it to degrade gracefully rather than assuming every device is as fast as the one on your desk. The method has four moving parts: favor cheap-to-render properties, avoid animating expensive layout, limit how much moves at once, and respect reduced-motion and low-power conditions. The job is to build for the slow phone, not the demo machine, because the device you tested on is almost never the device that struggles. Performance problems in motion are rarely surprises; they are the predictable result of designing animation in an environment that hides the cost.

The core of the method is choosing what you animate. Some properties are cheap for a device to render because the system can move a layer around without recomputing the page, and others are expensive because they force the browser or app to recalculate the position and size of everything around them on every frame. Animating transform and opacity, sliding, scaling, and fading a layer, is cheap, because the device just repositions a surface it has already drawn. Animating layout properties like width, height, or position that push other elements around is expensive, because the engine has to lay the page out again frame after frame, and that is exactly where a weak device drops frames and the motion turns to jank. Favoring the cheap properties is the single biggest lever, and the “design the animations on a fast machine and ship them” habit hides the cost of the expensive ones until a real device exposes it.

A designer feels the difference in a menu that slides in from the side. The expensive version animates the menu’s left position and width, so every frame the device recomputes where the page content sits, and on a flagship phone it looks perfect while on a three-year-old budget phone it stutters and tears. The cheap version starts the menu offscreen and animates a transform to slide it into place, moving a single composited layer the device never has to lay out again, and it stays smooth on the slow phone because the work per frame is trivial. Same visible motion, completely different cost, and the only change was animating a transform instead of a layout property.

The edge case is that cheap properties are necessary but not sufficient. Even cheap motion janks when too much of it runs at once, so a screen with a dozen simultaneous animations can overwhelm a weak device no matter how efficient each one is, which is why limiting concurrent motion matters. And graceful degradation has to include the user’s own signals: when someone has turned on a reduced-motion preference, you respect it by replacing or removing motion rather than ignoring the request, and respecting it correctly means offering a calm alternative like a simple fade or an instant change, not stripping the interface of all feedback. Low-power and low-end conditions deserve the same restraint, scaling motion down rather than pushing the same load onto a struggling device.

When you design an animation, build it for the slow device from the start. Reach for transform and opacity before anything that triggers layout, keep the number of simultaneous animations small, and wire your motion to honor reduced-motion preferences and low-power states with a graceful fallback rather than a hard stop. Treat the cheap-to-render path as the default and let the motion degrade quietly on weak hardware, so the budget phone gets a smooth experience instead of a stuttering one.