Part 6 · 2 chapters · ~20 min

Performance Budgets and Release Trains

Performance budgets as contracts per surface (bytes, lab and field metrics, runtime) with owners, a ratchet and an exception process that expires, and the release train as an operation: the cut, the rings, automatic gates, kill switches verified before the cut, the hotfix lane, and the release owner's authority.

13

Performance budgets enforced in CI

a contract per surface, with an owner
  1. Byte budgets per route: the entry chunk and first-screen transfer from the production build, compared against the budget and against main; over budget fails; growth beyond N KB without touching the budget file fails; treemap and delta posted. The surface team owns the file; the platform reviews changes to it (the Architecture course parts 1 and 5).
  2. Lab metric budgets: Lighthouse CI or a real-device lab runner on the preview deploy for the surface's key flows, per device tier, asserting LCP, INP (via a flow) and CLS medians over N runs; the trace attached for the DevTools method.
  3. Field metric budgets: the same metrics by route, release and tier from RUM, with alerts on p75 regressions between versions during the train's rings. The lab says what the change did on a test device; the field says what it did to users; both are required.
  4. Runtime budgets: main-thread time for the key interaction from a Recorder flow replayed in CI (the DevTools course part 9); memory after a scripted hour (the three-snapshot method automated); long tasks during a scroll. They catch the small-and-slow dependency the byte budget cannot see.
  5. The ratchet: a budget set at the current value and lowered a step each quarter, or to the best value seen ("no regressions from the best"). Without it the budget is a ceiling everyone grows into; with it, a slope.
  6. The exception: an owner, a reason, a size and an expiry date; CI accepts until the date; the dashboard lists active exceptions; an expired exception fails the build until renewed or resolved. The humane enforcement; the expiry stops it becoming the new normal.
PERFORMANCE BUDGETS ENFORCED IN CI
bytes, metrics and runtime costs per surface, owned by a team, with a ratchet and an exception process
swipe the figure sideways, or tap expand for full screen
1/6
bytes
Byte budgets: per route, the entry chunk and the first-screen transfer, measured from the production build in CI (the Architecture course part 1) and compared against the budget and against main (the delta). A PR over the budget fails; a PR that grows a route by more than N KB without touching its budget file fails; the treemap and the delta are posted. The budget file is owned by the surface team and reviewed by the platform when it changes.
14

The train at company scale

release engineering as an operation
  1. The cut at a fixed time: branch or tag the merge-queue head, build hermetically (part 1), run everything once, generate the changelog from landed changes and their OWNERS. 08:59 is on this train; 09:01 is on the next.
  2. The rings: internal dogfooding for an hour (a feedback button that attaches the version and a trace; a halt on a new error signature); 1% for four hours (field metrics by version and tier, guardrails, crash-free sessions, against the previous version on the same ring); 10% for a day; 100%.
  3. The gates, automated between every ring: no budget regression, no guardrail breach (part 5), crash-free and error rate by version within tolerance, no new error signature above a count, flag states as expected. A failure halts and pages the release owner; promotion otherwise needs no human.
  4. Kill switches: every feature on the train that could need turning off has a switch wired before the cut (a checklist the tool verifies); the release owner's page lists every switch with one-click off; a flip reaches clients within their poll interval, no new artefact (the Architecture course part 7's client you cannot recall, mitigated).
  5. The hotfix lane: a named approver from release engineering, a cherry-pick onto the current release, a shortened ring schedule, a post-hoc review of why it could not wait. Hotfix count is a health metric: rising means the cadence or the gates are wrong.
  6. The release owner: a rotation with a dashboard, the authority to halt and roll back without asking, a runbook per failure class with the lever and its time-to-fleet, and a handover note. The boring day is the goal; a halted train is the system working.
the transferable part
A fixed cadence, automatic promotion on numbers, switches wired before shipping, a hotfix lane with a count, and one person with the authority to halt. A team of thirty can run all five on a Tuesday train with a spreadsheet of switches; the machinery is what makes it hold at hundreds of changes per train.
THE TRAIN AT COMPANY SCALE
the cut, the rings, the gates, the kill switches, and the release engineer's day
swipe the figure sideways, or tap expand for full screen
1/6
the cut
The cut: at 09:00 on train days, the release tool branches from trunk (or tags the merge-queue head), builds the artefact hermetically (part 1), runs the full suite (the merge queue already ran affected tests; the train runs everything once), and produces a release candidate with a changelog generated from the landed changes and their OWNERS. A change that landed at 08:59 is on the train; one at 09:01 is on the next.