Performance budgets in CI/CD

A performance budget is a speed limit for a website or app, and teams are wiring those limits into continuous integration so slow code can block a merge before release. (web.dev) Google’s Lighthouse is an automated checker for web pages, and Lighthouse CI can run that checker on every commit or pull request inside a build pipeline. Its documentation says teams can fail builds when pages miss predefined criteria, including performance budgets. (developer.chrome.com, web.dev) Those budgets can be set on concrete numbers instead of gut feel: page weight, image count, or timing metrics such as Largest Contentful Paint, the point when the main content becomes visible. Sitespeed.io says a failed budget returns a non-zero exit code, which lets Jenkins, GitHub Actions, GitLab, and other pipeline tools stop the build automatically. (www.sitespeed.io, www.sitespeed.io, docs.github.com) The idea is older than the current wave of platform engineering. Web.dev wrote in 2018 that Lighthouse Bot could enforce a performance budget in Travis CI, and Chrome’s newer Lighthouse CI tooling keeps the same basic model: test every change, compare results, and reject regressions early. (web.dev, web.dev) What changed is where teams are putting the check. Instead of treating speed as a dashboard someone reviews after deployment, teams now run synthetic tests inside the delivery path, next to unit tests, security scans, and linting. Calibre’s documentation says pull request reviews can post a Markdown or JSON report and fail builds based on predefined budgets. (calibreapp.com, calibreapp.com) That setup fits the release math of continuous delivery. A regression caught in a pull request can be fixed in the same branch; a regression found after deployment usually means a rollback, an incident review, or a rushed patch. Lighthouse CI’s server also stores historical runs so teams can compare one build against another instead of arguing over a single test result. (googlechrome.github.io, web.dev) The hard part is choosing the budget. Calibre says budgets can be attached to every metric it tracks, but synthetic monitoring works best under controlled conditions — same device, network, and location every time — so teams do not confuse lab noise with a real slowdown. (calibreapp.com, calibreapp.com) Open-source and commercial tools take slightly different approaches. Lighthouse CI centers on audits and thresholds from Lighthouse reports, while Sitespeed.io can test multiple pages and user journeys and break a build if pages have too many assets, oversized assets, or slow timings. (web.dev, www.sitespeed.io, www.sitespeed.io) The trade-off is strictness. If a team sets budgets too tight, normal variance can create noisy failures; if it sets them too loose, the gate becomes ceremonial. The teams adopting these checks are betting that a small automated stop sign in the pipeline is cheaper than discovering, after release, that the product got slower one commit at a time. (calibreapp.com, www.sitespeed.io, web.dev)