6 Turn performance goals into budgets

Performance goals are useful because they define the user experience you want, but they do not stop gradual regression on their own. Performance budgets turn those goals into enforceable limits that code changes must respect, making growth visible before users feel the impact. The chapter argues that budgets are most effective when they reflect what the architecture can actually deliver, protect hard-won performance gains, and give engineers, tech leads, and managers a shared way to discuss trade-offs.

The chapter then explains what kinds of things to budget and how to choose the right thresholds. It covers memory, JavaScript bundle size, visual stability, API response time, database query time, startup time, and desktop input responsiveness, showing that different platforms need different measurements and checkpoints. It also emphasizes using representative devices and network conditions, keeping budgets tied to real users rather than developer machines, and setting thresholds with enough headroom to catch problems early while still being achievable.

Another major theme is granularity and governance. Some products work with global budgets, while others need per-route, per-endpoint, or phase-based budgets, especially when different teams contribute to the same experience. The chapter outlines clear ownership for technical decisions and exceptions, recommends lightweight documentation for budget changes, and describes escalation paths that match the size of the overage. Finally, it frames budgets as creative constraints: when teams treat them as shared challenges instead of arbitrary blockers, they often find simpler, better, and more user-friendly solutions, and when a budget stops fitting reality, it should be reset thoughtfully rather than quietly ignored.

Key performance budget types by platform. Memory usage is the only budget that applies across all platforms.

A budget allocation dashboard showing each team's current usage against their allocation. Core is nearly at capacity, while Analytics and Reserve have room for growth.

Budget exception escalation flow. Changes that fit within the budget merge without additional review. Changes that exceed the budget follow one of three paths depending on the size of the overage, with larger exceptions requiring more senior approval and more documentation.

An example performance budget document showing goals, current status with headroom, and the exception process.

Warning signs that a budget needs resetting. Any one of these suggests the budget no longer fits the product's current state.

• Budgets translate goals into thresholds you can enforce. Goals describe what users should experience; budgets describe what code changes are allowed.
• Budgets protect gains by making every addition visible against a fixed limit and forcing explicit trade-off conversations.
• Effective budget types vary by platform: JavaScript bundle size for web, API response time for backend, startup time and memory for mobile, launch time and resource consumption for desktop.
• Measure your baseline before setting thresholds. A budget without data is a guess.
• Start with global budgets, add per-page or per-feature granularity when variation affects users, and allocate headroom explicitly when multiple teams share a budget.
• Assign technical owners for routine decisions and exception owners for trade-offs that require broader context.
• Set budgets tighter than goals to catch problems early, then tighten further as performance improves.
• Your architecture constrains what budgets are achievable. Set thresholds your system can realistically deliver.
• Constraints drive creativity. Teams with tight budgets discover better architectures than teams with unlimited headroom.
• Budgets will break. Diagnose why, reset thoughtfully with phased approaches if needed, and make budget reviews a regular practice.

FAQ