Include inline startup scripts in the budget

When index.html contains an inline classic script, this passes an absent src to add and silently omits the script; the same happens to inline module scripts in the branch above. The browser still downloads that code as part of the HTML and executes it before the application renders, while the normal external Vite entry and preloads keep fromVite above the shape guard, so arbitrarily large inline bootstrap code can pass this startup budget. Measure executable inline script bodies or reject them explicitly.

Useful? React with 👍 / 👎.

Not reachable here, in either half.

An inline script authored in studio/frontend/index.html cannot execute: the backend serves script-src 'self' with no unsafe-inline (_build_csp in studio/backend/main.py), so the browser refuses it. That is exactly why the theme bootstrap is an external file, and the comment above the tag in index.html says so. Adding an inline script to the page would not grow the startup path, it would break the page, loudly and immediately.

The one inline script Studio does run is injected at request time by _inject_bootstrap with the per-response nonce, and it is never in dist/index.html, so no build-output check can see it or should try.

An inline module script with no src has nothing to fetch and nothing to resolve; that branch is not dropping a file, there is no file.

Leaving as is rather than measuring script bodies: the budget would then be pricing code the product forbids from running.

Normalize classic script MIME types before matching

When a same-origin startup script uses a valid parameterized JavaScript MIME type such as type="text/javascript; charset=utf-8", the browser executes it based on the MIME essence, but this exact set lookup rejects it. The Vite entry and preloads still satisfy the shape guard, so that classic script is silently excluded from both budgets; strip MIME parameters and whitespace before testing the classic type.

Useful? React with 👍 / 👎.

Checked this one and the premise does not hold: the browser does not run that script, so charging it would price bytes nobody fetches.

The type attribute is matched on JavaScript MIME type ESSENCE, and a parameter makes the whole value match nothing. The spec says so directly: 'scripts with their type attribute set to text/javascript; charset=utf-8 will not be evaluated' (https://html.spec.whatwg.org/multipage/scripting.html#attr-script-type).

Verified rather than assumed. Served three script tags from a local origin and watched the network:

text/javascript; charset=utf-8   chromium: not fetched, not executed
                                 firefox:  not fetched, not executed
                                 webkit:   not fetched, not executed
text/javascript                  all three: fetched and executed
application/javascript           all three: fetched and executed

Not even a request goes out, so there is nothing on the startup path to budget. Keeping the exact essence set, with that reasoning and the three-engine result recorded next to it, and pinned by 'a MIME type with parameters is not a script the browser runs'. The attribute-boundary item alongside this one was right and is fixed in e1702be.

Honor the backend's minimum gzip size

When an eager asset is smaller than 1,024 bytes, studio/backend/main.py serves it uncompressed because _AssetGZipMiddleware is configured with minimum_size = 1024, but this function always charges its gzip size. For small compressible chunks this can undercount almost the entire response body, so enough sub-1 KiB chunks can pass the transfer budget even though the bytes actually served exceed it; apply the same size threshold before using gzipSync.

Useful? React with 👍 / 👎.

Not taking this one, though the mechanism you describe is real and I checked it rather than assuming.

The backend config is as you say (studio/backend/main.py, minimum_size = 1024), and I read the Starlette source rather than the docs to pin the semantics: if len(body) < self.minimum_size and not more_body in _CompressionResponder.send_with_compression, identical at the installed 1.6.0 and at the 0.46.0 dependency floor. So it is a strict < (exactly 1024 IS compressed), measured on the first body chunk, and FileResponse uses a 64 KiB chunk size, so every sub-1 KiB asset does arrive as a single non-streaming message and does take that branch. Your premise holds.

What stops it is the magnitude. Measured on the current build:

charged by the gate   1,539,917
actually served       1,542,502
net undercount            2,585
headroom                 60,083

10 of 49 eager chunks are under 1 KiB. One of them, assets/array-BifhSqXX.js (107 raw, 112 gzipped), is currently overcharged, because gzip framing costs more than it saves at that size.

The undercount is bounded by 1023 bytes per sub-1 KiB chunk, so overtaking the headroom would take roughly 60 more maximally compressible sub-1 KiB eager chunks on top of the 49 that exist. That is not a build shape this app produces, and if it ever did, that shape is itself the anomaly the gate is meant to surface.

It is also below the precision of the thing it would be correcting: transferBytes is a hand-rounded 1,600,000 against a 1,503.8 KB measurement, and the model already ignores index.html and HTTP framing. A 0.17% systematic bias is a modeling approximation, not a gate that passes when it should fail.

Resolve relative same-origin startup URLs

When a classic startup script uses a relative URL such as src="theme-boot.js" or src="./theme-boot.js", the browser resolves and executes it relative to /index.html, but this leading-slash check silently rejects it. The normal root-relative Vite entry and preloads still satisfy the shape guard, so that script can grow without appearing in either budget; resolve same-origin relative URLs against the document URL or fail explicitly when one is encountered.

Useful? React with 👍 / 👎.

Reproduced, but not taking it, because the fix you propose makes the gate worse in a way an existing test already pins.

The mechanism is exactly as you describe:

src="/theme-boot.js"    blocking=["theme-boot.js"]   fromVite=3
src="theme-boot.js"     blocking=[]                  fromVite=3
src="./theme-boot.js"   blocking=[]                  fromVite=3

So it is an undercount and the shape guard does stay satisfied.

The problem is that a relative URL is not only how someone might write that one script tag, it is also what a base: "./" or base: "/studio/" build emits for EVERY href. tests/bundle-budget-cli.test.ts already settles what must happen then: "hrefs that are not site-root asset paths are reported, not silently skipped", asserting exit 2 and an error naming base, with the comment "Measuring the empty remainder as 0 bytes would pass forever."

I implemented your suggested resolution to check rather than argue from theory (new URL(url, "http://dist.invalid/"), origin compare, take pathname) and ran the suite:

not ok 5 - hrefs that are not site-root asset paths are reported, not silently skipped
# pass 7 # fail 1

That is the trade: resolving relative URLs counts your ./theme-boot.js, and in exchange a relative-base build stops erroring and starts reporting a comfortable pass on a set it has misread. The second failure is far more dangerous than the first, and it is the one this file exists to prevent.

Your alternative remedy, "fail explicitly when one is encountered", is what the code already does for the case that actually occurs.

On reachability, this one also announces itself rather than lying quietly. Vite warns at build time on a relative classic src (<script src="./theme-boot.js"> in "/index.html" can't be bundled without type="module" attribute), and the backend serves index.html from a catch-all, so on the one nested route a relative src fetches /data-recipes/theme-boot.js, gets index.html back as text/html, and is refused execution under the app-wide X-Content-Type-Options: nosniff. The two parser items I fixed earlier this round had no such signal anywhere: the app behaved perfectly and only the gate was wrong.

Preserve query strings when deduplicating requests

When the same local startup script is included under distinct cache-busting URLs such as /boot.js?v=1 and /boot.js?v=2, the browser treats them as separate requests and executes both classic script elements, but stripping the query before the shared seen check collapses them to one measurement. This can undercount both transfer and execution cost while the Vite chunks keep the shape guard satisfied; retain the complete request URL as the deduplication identity while using only its pathname to locate the file.

Useful? React with 👍 / 👎.

Reproduced, and rejecting on reachability.

The collapse is real:

<script src="/boot.js?v=1"><script src="/boot.js?v=2">  ->  blocking=["boot.js"]

Two requests, two executions, one measurement.

What it needs is an index.html that deliberately includes the same local boot script twice under two cache-busting query strings. Vite cache-busts by content hash in the filename and never by query string, and files copied from the public dir keep their names verbatim, so no build emits this. The real dist/index.html contains zero ? characters and exactly two src values, /theme-boot.js and the hashed entry.

That leaves a hand edit whose own content is the defect: loading and executing the same boot script twice does visible duplicate work, and the double byte count is the least interesting thing wrong with it. Fixing the accounting for a document that is already broken in a louder way is not what this gate is for.

Worth noting the dedupe is not incidental either. seen exists because the entry chunk can legitimately appear as both a <script src> and a <link rel=modulepreload>, where the browser really does fetch it once, and that is the case it has to get right.

Include the backend-injected bootstrap script

On first-boot local and Colab requests, the measured file is not the HTML the browser executes: studio/backend/main.py lines 2075-2100 inject a nonced inline window.__UNSLOTH_BOOTSTRAP__ script before </head>, and lines 2327-2336 authorize it through CSP. Fresh evidence versus the earlier inline-script thread is that this backend-generated script is currently reachable despite the static page's CSP. Reading only dist/index.html therefore omits its transfer and execution bytes, and future growth of that bootstrap can pass this startup budget unnoticed; include the injected script in the measurement or derive the measurement from the served response.

Useful? React with 👍 / 👎.

You are right that the CSP objection from the earlier inline-script thread does not apply here, and that is a fair distinction to draw. It still does not get this over the bar, on size and on scope.

Size. I measured the tag rather than estimating it. It is

<script nonce="...">window.__UNSLOTH_BOOTSTRAP__={"username":...,"password":...}</script>

with a 22 character nonce and a four word diceware passphrase: 142 bytes. Substituting an absurd 64 character password gives 178. That is 0.009% of the 1,600,000 transfer budget. For consistency, I declined a separate suggestion this round about the backend's 1 KiB gzip threshold at a measured 2,585 byte discrepancy against 60,083 bytes of headroom; this is eighteen times smaller than the one I already judged immaterial.

Growth. The payload is not open ended, which is what "future growth can pass unnoticed" would need. It is exactly two fields, a fixed username and a password. Adding a third would be a change to what credentials get handed to the browser, reviewed on its own terms and not something a bundle budget should be the tripwire for.

Scope. This gate guards one specific regression: a static import pulling something into the entry closure, the way a dialog that is closed on load was carrying 2.4 MB. No frontend import can affect this tag. It is generated per request by the backend, only when requires_password_change holds and a bootstrap password exists, so it is a first-boot condition rather than the steady state.

Feasibility of the alternative. "Derive the measurement from the served response" would mean booting the backend inside the frontend build job and driving it into a first-boot password-change state, to attribute 142 bytes. The gate runs at build time against dist/, where no backend exists. That is a large amount of new machinery, and a new way for the check to fail for reasons unrelated to bundle size, bought for four thousandths of a percent of the budget.

The narrower reading, that the file measures dist/index.html and not the served response, is fair. That is deliberate: what it measures is the build output, because the build is what a pull request changes.

Require a module entry before trusting preloads

When the module entry is missing or rewritten into an unsupported form while at least two modulepreload links remain, this sum still satisfies the shape guard and the command exits successfully after measuring only the preloads. This is precisely the malformed/changed build shape the guard is intended to reject: for example, an HTML transform that rewrites the entry URL but leaves its preload links lets the entry's bytes disappear from both budgets. Check that entry is nonempty independently, while continuing to allow multiple entry scripts with no preloads.

Useful? React with 👍 / 👎.

Agreed, and fixed in a71ff98.

This is the residue of the two parser bugs fixed earlier in this branch, and you have put your finger on why they were able to hide. Both did their damage the same way: the entry dropped out, the 48 preload links kept fromVite well above 2, and the gate measured the remainder and reported a comfortable pass. I fixed the causes. The invariant that would have made either one loud was still missing, which is what you are pointing at.

Your reasoning about the shape is the part that convinced me. A modulepreload link exists to announce the entry's static import closure, so links cannot legitimately outlive the entry they hang off. Preloads with no entry is not something Vite emits; it means the entry was read wrong. And it is the worst possible place for the guard to have a hole, because the entry chunk is the largest single item on the startup path here, 430 KB raw and 128 KB transfer.

The guard now requires entry to be non-empty in addition to the total, with a distinct message for that case. Your caveat about not breaking the multiple-entries-no-preloads layout was well taken and is exactly right: the total still decides whether this is a code-split build, so the inlined-entry case, where Vite emits one module script per imported chunk and no links at all, still passes as a complete measurement. Its test is unchanged and still green.

Regression test removes the entry script from the fixture and asserts exit 2 with "no module entry". Reverting the script with the test kept fails exactly that test. 41 bundle tests, full suite 2885 passed / 0 failed on node 22, and the real build is unaffected at 5225.1 KB raw / 1503.8 KB transfer / 49 chunks.