Performance Budgets That Actually Ship: A Practical Guide

Performance budgets are one of those practices every team agrees is a good idea and almost nobody implements. In 34 client codebase audits over two years, exactly two had performance budgets in their CI pipeline. The other 32 had "add performance monitoring" gathering dust in the backlog behind feature work.

We started enforcing budgets across all our projects 18 months ago. Our median Lighthouse score went from 72 to 91. More importantly, it stayed at 91 because the budget prevents regression. Before budgets, performance gradually degraded as features were added. Each feature added a few kilobytes of JavaScript, a couple of extra API calls. No single change was noticeable. After six months, a site scoring 95 at launch would score 65.

Our system has three layers. Build-time checks using bundlewatch enforce maximum bundle sizes: main bundle under 150KB gzipped, route bundles under 50KB, total CSS under 30KB. Developers see warnings immediately on local builds.

CI gates using Lighthouse CI run on every pull request. Thresholds: Performance above 85, LCP under 2.5 seconds, CLS under 0.1, INP under 200 milliseconds. If any threshold fails, the PR is blocked from merging. This is the enforcement mechanism that makes budgets real instead of aspirational.

Production monitoring using the web-vitals library collects real user metrics continuously. We track P75 values and alert when any metric degrades 10% from the rolling 7-day average, catching regressions that synthetic CI testing misses.

Budgets vary by project type. Marketing sites: Performance above 95, LCP under 1.5 seconds, JS under 100KB. SaaS dashboards: Performance above 80, LCP under 3 seconds, JS under 300KB.

The most common violations: importing entire libraries for one function, loading third-party scripts synchronously, unoptimized images, unused CSS, and sequential API calls that could be parallelized.

The hardest part is organizational commitment. When a deadline approaches and a PR is blocked, pressure builds to increase the budget. We resist every time because a budget raised whenever it is inconvenient is not a budget. We find optimizations instead: lazy loading, lighter library alternatives, deferred JavaScript. In every case, we have found a way to meet the budget without cutting features. Start with CI gates. They take an afternoon to set up and they keep your application fast permanently.