The Budget That Counted Nothing
Last year this site shipped 4.11 MB on every page load. Most of it was a JavaScript compiler downloaded from a public CDN so the browser could compile my source at runtime, on every visit, for every visitor. I fixed it, wrote about it, and then did the thing you're supposed to do after fixing something: I wrote a test so it couldn't come back.
The test was a byte budget. Add up everything the home page loads; fail if it exceeds 1.6 MB. It has been green every night since.
Last night I finally looked at the number it was reporting.
PASS home payload budget — 97 KB <= 1563 KB
Ninety-seven kilobytes. For a page that loads React, React DOM, a 636 KB 3D library, a 120 KB application bundle, a 69 KB stylesheet and a photograph of my face.
Absent is not zero
The measurement was one line:
bytes += Number(r.headers()["content-length"] || 0)
Which is a perfectly ordinary way to ask how big a response was, and it is correct whenever the server says. Mine doesn't. The suite serves the site from a small static server that calls writeHead() and then end(buffer) — by the time the buffer shows up, Node has already serialised the header block, so it can't go back and add a Content-Length. It falls back to chunked transfer encoding, which is a completely valid way to send a response and simply doesn't advertise a length.
So r.headers()["content-length"] was undefined. And Number(undefined || 0) is 0.
Every first-party asset — the whole site — contributed exactly nothing to the total. I dumped the per-resource numbers to be sure:
651651 real | 0 CL | /vendor/three.min.js
131835 real | 0 CL | /vendor/react-dom.production.min.js
123082 real | 0 CL | /portfolio.js
70361 real | 0 CL | /styles.css
48256 real | 48256 CL | fonts.gstatic.com/…/inter.woff2
The 97 KB was three font files from Google's CDN. A real CDN, which sets the header. My budget had been measuring the only bytes on the page I don't control, and none of the ones I do.
The real total was 1,224 KB. Still under the 1.6 MB limit, so the assertion's verdict was accidentally right, which is how it survived. But the guard existed for exactly one purpose — to stop a multi-megabyte bundle from creeping back in — and it was structurally incapable of noticing one. I could have re-added the 3 MB compiler from my own /vendor/ directory and the number would not have moved a single byte.
The shape of this bug
What bothers me isn't the missing header. It's that the failure produced a good number.
If the measurement had broken loudly — thrown, or returned NaN, or reported a negative — I'd have caught it the first night. Instead the broken path and the ideal path produce the same output. A page that ships nothing and a page you failed to measure both look like zero. The test was not just wrong; it was wrong in the direction that reads as success, which means every night it ran, it was actively reassuring me.
I've now hit this three times on this one small site, and it's the same shape every time. A check that enumerated four surfaces and stayed green while a fifth drifted. A checklist of eight accessibility assertions, all green, on pages that failed WCAG at Level A. And now a budget that summed to zero and called it a pass. Different subsystems, same defect: the assertion was fine, and the thing underneath it wasn't doing what I believed.
What connects them is that in all three cases the failure mode and the healthy state were indistinguishable from the outside. That's the property to hunt for. Not "is this check correct?" — mine were all correct — but "if this check quietly stopped working, would tonight's output look any different?"
For the budget, the answer was no. Which means it wasn't really a test. It was a habit.
The fix, and the second fix
The measurement now reads the actual response body rather than asking the server how big it was going to be. It counts every byte whether or not anyone advertised a length.
Then I did the thing I should have done a year ago, which is look at what the honest number was made of. 636 KB of the 1,224 KB — over half the page — was a 3D library rendering one decorative crystal in the hero. It's marked aria-hidden. It conveys nothing. It isn't drawn at all if you've asked for reduced motion, or if your viewport is narrow, or if WebGL is unavailable. And it was downloading on every one of those visits anyway, as a plain <script defer>, competing with the content for bandwidth.
It now loads only when it's going to be used: motion allowed, viewport wide enough, hero actually near the screen. On a phone, the ornament costs zero bytes instead of 636 KB.
That saving was always available. I just couldn't see it, because the instrument pointed at it was reporting 97 KB.
What I'm taking from it
Read the number, not the verdict. I had looked at that line hundreds of times and only ever registered the word PASS. The number sitting next to it was absurd on its face — 97 KB for a page with a 3D engine on it — and it was printed in front of me every single night.
Treat a missing measurement as a failure, not a zero. Anywhere a default silently substitutes for a reading, you have a path where "we didn't measure" renders as "we measured, and it was perfect." || 0 is where I'd start looking.
Assert that the instrument is alive. The budget should have refused to pass at all if the total came in under, say, 50 KB — because that isn't a lean page, it's a broken scale. A check that can only fail one way can only find one kind of problem.
Break it on purpose once. Same conclusion I reached two essays ago and evidently need to keep re-learning: an assertion nobody has watched fail is a hypothesis. If I'd ever added a large file and watched the number climb, I'd have found this in a minute.
A missing measurement and a perfect score are the same number. Only one of them is true.