A budget must be checked in the build pipeline

What it is

A cap that lives in a document, and is not run automatically on every change, has no teeth at merge time. The budget has to enter the build pipeline: after the bundle is produced, compare size, run the lab profile on a preview, hang the result on the pull request, and fail — or escalate to a warning that must be handled — when the cap is crossed. Hoping someone opens a spreadsheet before release is not a check.

The check lives in the pipe, not in a one-off audit on a laptop. Local numbers are unstable and will not re-run when someone else changes the product.

Why it happens

The pipeline runs on every change in a relatively fixed environment; people do not. Once bytes, request counts, or lab timings are a pipeline step, going over budget has the same kind of blocking point as a failed test or a type error. Without that step the cap exists when someone remembers, and remembering happens after the feature is merged, when taking it back is expensive.

Local checks also lie: a proxy, an empty cache, half the feature flags off. The pipeline uses the same install and the same build command, so the number corresponds to the artifact that will ship. The check also has to be visible: a size diff on the pull request, the crossed line in the failing log, so “over” is an input to the discussion rather than a surprise after release.

Where it stops holding

A design prototype with no product pipeline cannot enter a build; do not pretend a check exists. Hotfix and incident lanes may skip in writing, but the skip must leave an overage record and a time to re-run; a silent skip pulls the teeth. A check that only counts bundle bytes and never runs on a realistic preview will miss request waterfalls and third-party scripts; a size gate is still useful, just not a complete check. Native binary size may live on a different pipeline (store packaging); a web CI step cannot see it and must be attached to that lane rather than idling in web CI. Fully offline, hand-published static work needs a pre-publish script that still compares numbers; “we have no CI” is not a reason to skip the comparison.

Applying it

• Wire each budget as a pipeline step: script bytes, request count, or time on the lab profile. Fail by default; do not only post an ignorable comment.
• Show the diff against main on the pull request. An overage needs an owned handling action before merge.
• Skip lanes (hotfix) leave an overage record and a re-run; an unlogged skip is forbidden.
• How to check: add an obviously oversized asset on a branch and watch whether the pipeline fails or raises a must-handle overage. All green, asset already in the bundle, means the check never entered the build. Pack again with local network off; if the size problem is visible only then, everyday enforcement was a person, not the pipe.

Related

• Same group: R3.04.1 A budget must be bound to a specific device and network · R3.04.2 A performance goal with no budget will not be executed
• Nearby: I2.07 Perceived performance · R3.15 First-paint metrics and interaction readiness
• Search terms: performance budget CI · size-limit · fail build on budget