Performance Budgets in CI/CD

The plain-language idea

The earlier performance-budgets lesson in this track covered what a budget is and how you'd set the number — a bundle-size ceiling, an LCP threshold, whatever the team agreed on. That's necessary but not sufficient: a budget nobody enforces is just a number in a document that everyone forgets under deadline pressure. This lesson is about the enforcement mechanism — making the budget structurally impossible to silently violate.

The pattern is the same discipline as a test suite gating a merge, applied to a performance number instead of correctness: a CI step runs after a build, measures something concrete against the budget (a bundle-size check against the build output, or a Lighthouse run against a deployed preview), compares the result to the configured threshold, and either fails the build outright or, at minimum, posts the delta as a PR comment so a human has to consciously acknowledge it before merging. Either way, the regression becomes visible before it reaches production, tied to the specific commit that introduced it, instead of being discovered weeks later when someone happens to notice the site feels slower.

See it in a real thing: a bundle-size gate on every PR

# .github/workflows/bundle-check.yml
- name: Build
  run: pnpm build

- name: Check bundle size against budget
  run: npx bundlesize

// bundlesize.config.json
{
  "files": [
    { "path": "dist/main.*.js", "maxSize": "170 kB" }
  ]
}

If the built main bundle exceeds 170 kB, this step exits non-zero, the CI check goes red, and the PR is blocked from merging (or clearly flagged, depending on how strict the team wants to be) until the size is addressed or the budget is deliberately revised. Nobody has to remember to check; the pipeline checks for them, every single time, on every single PR.

What people usually miss

Watch out

• The value isn't catching one big regression — it's catching many small ones before they compound. A slightly heavier dependency here, an unoptimized image there: each is too small to notice in manual testing, but they accumulate into a real problem over months. An automated check catches each one the moment it's introduced.
• "Cheapest to fix" is a real, not rhetorical, claim. A regression caught in a PR is attributable to one commit, with the author still in context. The same regression caught three months later in a retrospective audit requires someone to first figure out which of dozens of merged PRs is responsible.
• A budget check needs a clear owner for exceptions. Real features sometimes legitimately need more bytes. A hard-fail check without an easy, reviewed path to adjust the budget just trains people to find workarounds instead of having the actual conversation.
• Bundle-size checks and Lighthouse-based checks catch different things. A bundle check catches "this PR shipped more JS." It says nothing about whether that JS actually delays LCP or INP in practice — that's a separate, complementary check.

Why this matters in interviews

"How would you stop performance regressions from shipping without relying on people remembering to check manually?" tests whether a candidate reaches for process and tooling (an automated, enforced gate) or just proposes "we should test more," which is precisely the kind of good intention that erodes under deadline pressure.