Back to blog
Performance Apr 12, 2026 6 min read

Performance budgets in CI: stop regressing in production

How to enforce performance metrics in your pull request workflow so regressions never reach production.

article.body

Why production regressions happen

Every performance improvement is one feature away from being undone. A new analytics tag adds 80kb of JS. A new hero image adds 1.2s to LCP. A new third-party widget adds 200ms to INP. Each is a small change shipped in a single PR, none reviewed for performance impact. Six months later, your CWV scores are back where they started.

The budget concept

A performance budget is a hard limit on a measurable metric — total JS size, total CSS size, LCP, INP, CLS, image bytes. When a PR exceeds the budget, the CI fails the check and the PR can't merge until either the regression is fixed or the budget is explicitly raised (with a justification).

What to budget

Start with three budgets: total compressed JS shipped on the homepage, LCP at the 75th percentile, INP at the 75th percentile. These three cover 80% of CWV regressions. Add more granular budgets (CSS size, font count, third-party request count) once the foundation is in place.

Tools

Lighthouse CI is the most common tool. It runs Lighthouse against your PR's preview deployment and fails the check if scores drop below thresholds. SpeedCurve, Calibre and Cloudflare Web Analytics offer more sophisticated budgeting with real-world data. Pick the tool that fits your stack — but ship something, even if it's basic.

Setting the thresholds

Don't set budgets based on aspirational targets — you'll fail every PR. Set them based on current production performance, with a small safety margin. As you ship improvements, tighten the budgets. The budget should always be slightly tighter than current production — it ratchets quality up over time.

Handling exceptions

Sometimes a PR legitimately needs to add weight. A new product launch adds a new hero image. A new feature requires a new dependency. The budget should be raisable, but raising it requires a documented justification in the PR. The friction is the feature — it forces a conscious tradeoff.

The cultural shift

Performance budgets work when the team treats performance as a feature, not a nice-to-have. The first time a PR fails the budget, the engineer's instinct is to ask 'how do I disable this'. The right answer is 'how do I fix the regression'. Lead engineers and managers need to back the budget, every time, for it to stick.

Want this for your site?
Get in touch with our SEO experts.
Contact us