v10r

Budgets are worth little if nothing enforces them, and unenforceable if they fail on the day they land. This separates the two jobs: targets say where we want to be, ratchets stop today's number becoming tomorrow's floor.

Targets

Where the build should get to. Scored and displayed, never build-failing.

Metric	Current	Warn / fail	Verdict
`route_js_kb`	502.1 KB	150 / 250	Poor
`baseline_js_kb`	94.1 KB	80 / 120	Needs work
`doc_html_kb`	3.6 KB	50 / 100	Good

The heaviest route is well over its target, and saying so plainly is the point. A dashboard that only shows green has stopped being a measurement.

Ratchets

The measured value at the moment it was accepted. These fail the build when exceeded, and only ever move down — lowering one is how an improvement gets banked.

Metric	Current	Ceiling	Slack (KB)
`route_js_kb`	502.1	520	+17.9
`baseline_js_kb`	94.1	97	+2.9
`median_route_js_kb`	229.7	238	+8.3
`total_client_js_kb`	2140.8	2210	+69.2
`doc_html_kb`	3.6	5	+1.4

Why bundle size specifically

Not everything belongs in a gate. Bundle weight is unusually well suited to one:

It is invisible in review — a one-line import can add a hundred kilobytes with nothing in the diff to show it.
It is deterministic — the same source produces the same number, so the check does not flake.
It is only catchable before shipping — by the time real-user data reflects it, users have already downloaded it.

Measured 2026-10-24 · NODE_ENV=production

Think this pattern could be better? Tell us how.

Leave feedback