Performance Budgets

Best Practice: Performance Budgets

A performance budget is a set of quantitative limits that a page or app must not exceed. Budgets can cover resource sizes (total JavaScript, images, fonts), request counts, or timing metrics such as Largest Contentful Paint and Interaction to Next Paint. The idea was popularized by Tim Kadlec and Google's web.dev guidance. Budgets matter because performance erodes slowly as features ship; each new dependency, tracking script, and component adds weight that no single change seems responsible for. A budget makes that erosion visible and enforceable, turning a vague goal of staying fast into a concrete number that a pull request can pass or fail. This protects Core Web Vitals, search ranking, conversion, and user retention, and it gives non-engineering stakeholders a shared metric to reason about.

Step-by-Step Implementation Guidance

1. Measure current performance to establish a baseline.
2. Choose budget types: milestone timings, quantity metrics, or rule-based scores.
3. Set realistic limits, for example a JavaScript bundle cap and an LCP target under 2.5 seconds.
4. Encode budgets in tooling, such as a Lighthouse CI assertion or bundler size limit.
5. Fail the CI pipeline or warn on pull requests when a budget is exceeded.
6. Review budgets periodically and tighten them as the codebase improves.

Common Mistakes Teams Make When Ignoring This Practice

• Measuring performance once at launch and never again.
• Setting budgets without enforcing them in CI.
• Tracking only lab metrics and ignoring real-user data.
• Letting third-party scripts grow unchecked outside the budget.
• Defining budgets so loose they never trigger.

Tools and Techniques That Support This Practice

• Lighthouse CI for assertion-based budgets.
• bundlesize, size-limit, and webpack performance hints.
• WebPageTest and the Chrome User Experience Report for field data.
• The browser Performance API and RUM tools for real-user monitoring.

How This Practice Applies to Different Migration Types

• Cloud Migration: Verify new CDN and edge configs keep payload and latency within budget.
• Database Migration: Track server response time as a budget input affecting LCP.
• SaaS Migration: Budget the weight of embedded vendor scripts before adopting them.
• Codebase Migration: Set a budget on the new framework's bundle to prevent silent bloat.

Checklist

• Baseline metrics measured.
• Budget types and limits defined.
• Budgets encoded in tooling.
• CI fails or warns on breach.
• Third-party scripts counted in the budget.
• Field data tracked alongside lab data.
• Budgets reviewed on a schedule.