RENDER BUDGETS AS DESIGN MATERIAL.

//The number#

Sixty frames per second gives you 16.7 milliseconds per frame, and the browser needs several of those for its own work. Realistically you have around ten to spend on script, style, layout and paint combined. That's the budget. It doesn't expand because the design is ambitious, and on a mid-range phone the effective figure is closer to five.

//Why it belongs in the design phase#

Because the expensive decisions are made there, not in the implementation. A backdrop blur across a full-width sticky header is a rasterisation cost on every scroll frame. A box shadow animated on hover forces a repaint; the same effect with opacity on a pre-rendered layer doesn't. These aren't implementation details — they're choices between visually similar options with wildly different costs, and the cheapest moment to make them is before anything is built.

I've started bringing a cost estimate to design review. Not a lecture: a note that this particular effect costs roughly four milliseconds per frame on the target device, so if we want it here, something else has to go. That turns performance from an engineer saying no into a shared trade-off with a number attached, which is a conversation designers are generally happy to have.

//Spending it well#

Transforms and opacity are the cheap properties because they can be handled by the compositor without layout or paint. Everything else — width, height, top, left, box-shadow, filter, backdrop-filter — costs more, sometimes dramatically. A reasonable rule: if it animates, it should be a transform or an opacity. If it can't be, ask whether it needs to animate.

And measure on the cheapest device in your actual analytics, not the one on your desk. The gap between those two machines is where most shipped performance problems live.