How to Set Up Performance Budgets in CI/CD Pipelines

A performance budget in production is a line you refuse to cross. In CI it is the same line, enforced before a merge or deploy lands. Done well, the pipeline fails fast when a change regresses Core Web Vitals proxies, bundle weight, or your own custom thresholds, so you fix it in the branch instead of shipping first.

Most teams start with Lighthouse CI: controlled Lighthouse runs, stored results, and assertions against numeric ceilings. Pair lab gates with bundle size limits when regressions come from dependency drift rather than layout alone. CI answers whether this build broke your thresholds on the URLs you chose; scheduled monitoring answers whether you are still inside budget next week across the pages you track in production.

Before you write YAML, pick URLs and environments that are deterministic enough to trust. Preview deploys from Netlify, Vercel, or Cloudflare Pages work if the job waits until HTTP 200. Document home, a heavy template, and checkout or app shell if those differ. One URL with a loose budget hides regressions on another.

A credible CI budget checklist:

• List representative URLs, not only the homepage

• Set numeric thresholds aligned with your team policy or client contract

• Run at least two Lighthouse passes per URL to reduce cold-start noise

• Probe preview URLs with retries before lhci autorun

• Add at least one JS or CSS bundle guard alongside LCP and CLS gates

• Separate error vs warn assertions until baselines settle

If you already use performance budgets and email alerts in Apogee Watcher, treat CI as the pre-merge gate and Watcher as the continuous check on real site inventories. Same vocabulary, different phase of the lifecycle.

Read more: how to set up performance budgets in CI/CD pipelines