Public: anyone can read this; the crew can change it.
/next has no script-size ceiling in docs/design/size-budget.json #12383
Check · Review · Land · Live done — Landed and live in production.
`/next` now has a script ceiling in `docs/design/size-budget.json`, measured on this branch: 23040 B JS and 44032 B CSS, gzip.
shipped production is serving it deploy 44b6735
/next now has a script ceiling in docs/design/size-budget.json, measured on this branch: 23040 B JS and 44032 B CSS, gzip.
The ceiling file and the budgeted pages must match exactly, so I also added /:owner/:name/next to the page-load budget in src/perf/page_budget.ts. That entry is 50 ms median and 64 SQL statements, measured at 62 warm.
The size test measures the page as a signed-in writer, because KEYS_JS only ships for writers. DRAG_JS is not in the page's own source (next.ts references only KEYS_JS), so I did not confirm it is counted; the ceiling covers whatever the page serves.
I updated the page-count assertion in test/page-budget.test.ts from eight pages to nine.
FORGE_SIZE_WRITE=1 also bumped the CSS ceiling on every other page by 256 B, because it rewrites all of them from today's measure. I reverted that. Only the new /next entry is added, and no existing ceiling changed.
The client-size and page-budget tests pass and bun x tsc --noEmit is clean. I did not run scripts/gate.ts (the file does not exist in this clone), and I ran four test files rather than the 85 files scripts/fast.ts named, which it estimated at 6m42s.
To try it: bun test test/client-size.test.ts test/page-budget.test.ts.
🤖 Generated with Claude Code
Small, single-purpose, and it does what the issue asked: /next gets a gzip ceiling (23040 B JS, 44032 B CSS) and the ceiling file still matches the budgeted pages exactly. Nothing else changed: no other ceiling moved, no code, no dependency. The page-count assertion is updated to match. The preview boots and answers 200 on /. I could not render /next on it as a person would: /trevato/forge/next returned 404 for me, so I could not look at the page itself.
Two things I would do next:
- Put 64 statements in context. /next is budgeted at 64 SQL statements against 49 for an app page, and the measured 62 leaves two of headroom. That is a lot of queries for one page on a pipeline-first, 50 ms-median forge. Open an issue to batch them down, then tighten the limit.
- Confirm DRAG_JS is counted. The pull says next.ts only references KEYS_JS, and the ceiling is measured as a writer. Add a test line, or a note beside the ceiling, saying which scripts the 23040 B covers, so a later change that ships drag script to /next trips the budget and does not quietly fit under it.
/nextnow has a script ceiling indocs/design/size-budget.json, measured on this branch: 23040 B JS and 44032 B CSS, gzip.The ceiling file and the budgeted pages must match exactly, so I also added
/:owner/:name/nextto the page-load budget insrc/perf/page_budget.ts. That entry is 50 ms median and 64 SQL statements, measured at 62 warm.The size test measures the page as a signed-in writer, because KEYS_JS only ships for writers.
DRAG_JSis not in the page's own source (next.tsreferences onlyKEYS_JS), so I did not confirm it is counted; the ceiling covers whatever the page serves.I updated the page-count assertion in
test/page-budget.test.tsfrom eight pages to nine.FORGE_SIZE_WRITE=1also bumped the CSS ceiling on every other page by 256 B, because it rewrites all of them from today's measure. I reverted that. Only the new/nextentry is added, and no existing ceiling changed.The client-size and page-budget tests pass and
bun x tsc --noEmitis clean. I did not runscripts/gate.ts(the file does not exist in this clone), and I ran four test files rather than the 85 filesscripts/fast.tsnamed, which it estimated at 6m42s.To try it:
bun test test/client-size.test.ts test/page-budget.test.ts.🤖 Generated with Claude Code
Closes #12380