Bytes on the wire

This site was no-build on principle: every page inline, every byte committed the way it ships. This is the story of the first build step that earned its place anyway, the brotli rabbit hole that led there, the Oxc and Lightning CSS knobs that survived contact with the real site, and the cache layer that finally made a header the site had been sending for months actually do something. Every number below was measured on this site, most of them twice.

Where compression actually happens

The naive model says "Cloudflare serves brotli, so the bytes are as small as brotli gets." The real model has tiers. Brotli has quality levels 0 to 11: level 11 is the slow, offline, squeeze-everything setting, and no CDN runs it on the fly, because compressing at q11 costs more time than it saves. Cloudflare's edge compresses dynamic and pass-through responses at roughly gzip quality. Measured on the homepage: the edge served 31,360 bytes as brotli and 31,188 as gzip, nearly identical. A local brotli q11 of the same document: 25,099. That gap, roughly 12 to 16% on every text asset, is the room between what the edge does in microseconds and what q11 does offline.

Four roads to q11, all closed

• Native brotli in the Worker. There is none. Workers' CompressionStream speaks gzip and deflate only. Dead end by platform design.
• wasm brotli at q11, per request. The homepage re-renders per visit (random photo grid + live counter), so it would compress on the hot path: multi-ms of CPU per request plus a wasm blob in the bundle to save ~6KB. Rejected on arithmetic.
• Worker-side gzip level 9. Measured a local gzip-9 of the homepage at 31,204 bytes vs the edge's 31,207. Three bytes. The edge's gzip is already at the ceiling; only brotli has headroom, and see above. Rejected as a no-op.
• Precompressed .br twins. The interesting one. Pages ignored uploaded .br files (tested, it served the plain twin). Workers CAN do it: fetch the twin from assets and return it with content-encoding: br and encodeBody: "manual", which tells the runtime the body is already compressed. But that means the asset goes back through the worker (undoing the zero-invocation edge-direct routing), plus Accept-Encoding negotiation and Vary correctness, to beat the edge's own brotli by ~3KB on a file that was about to get much smaller anyway. Rejected, narrowly, with the next section as the reason.

The build step that earned its place

The shell scripts are the one external asset class: nav.js (the whole XP desktop: taskbar, draggable windows, Run palette) rides on every page. It is written the way this site writes everything: essay-grade comments, because the comments are the documentation and half the voice. That costs nothing in git and a meaningful part of the 82.8KB source file. Compression does not forgive all of that prose.

So the split, and the compromise that finally justified a build: the authoring stays buildless, the serving gets minified. One script (build.mjs) stages a copy of the site, runs Oxc Minify 0.140.0 over six independent client scripts, runs Lightning CSS 1.32.0 over the shared stylesheet and marked Worker CSS literals, and deploys from the copy. The repo never changes; local dev still serves the readable versions directly.

The other five shells are notepad.js, lens.js, lens-browser.js, quiz.js, and tooltip.js. sw.js is now a tiny unregister stub and stays readable. Garage pages remain deliberately untouched: View Source on this site is supposed to read like source. The homepage now gets the same authoring/serving split, but only in the staged copy, with its readable original kept as /index.src.html.

/*! minified at deploy - readable source: /nav.src.js */

The inline-block wrinkle

External nav.js and luna.css have an obvious place to put smaller bytes. The homepage also carries a large inline <style> block and several inline <script> blocks. Those are not pointers to the external files: the code is literally inside the HTML document, so minifying the shells and stylesheet never touched it.

The new profile closes that hole conservatively. Rust-backed @minify-html/node handles document structure with its own JavaScript and CSS transforms disabled. Before that pass, homepage inline CSS goes through the existing Lightning CSS settings and executable inline JavaScript goes through the existing Oxc settings. JSON-LD and speculation rules are data, not JavaScript, so they remain untouched.

What about the CSS?

Minifying CSS is the same idea as minifying JS, and worth seeing side by side, because the two languages do not shrink the same way. Both snippets below are real code from this site (the scroll-remember helper from nav.js, and this very page's Luna close-button gel), run through their native minifiers. Byte counts are for the full block; the excerpts are trimmed to fit.

function rememberScroll(sc) {
  var key = "axp-scroll:" + location.pathname;
  var save = function () {
    try { sessionStorage.setItem(key,
      String(sc.scrollTop)); } catch (e) {}
  };
  var nav = (performance.getEntriesByType &&
    performance.getEntriesByType("navigation")[0]) || {};
  if (nav.type === "reload") { /* ... */ }

function rememberScroll(e){var t="axp-scroll:"
+location.pathname,r=function(){try{
sessionStorage.setItem(t,String(e.scrollTop))}
catch{}},s=performance.getEntriesByType&&
performance.getEntriesByType("navigation")[0]
||{};if(s.type==="reload"){/* ... */}

.title-bar .controls .close {
  position: relative; box-sizing: border-box;
  width: 21px; height: 21px; padding: 0;
  border: 1px solid #6696eb; border-radius: 3px;
  background-image: linear-gradient(180deg,
    #e8795f 0%, #e45f40 30%, #e45d3d 52%,
    #e2552a 80%, #ae3110 100%);
  transition: filter 60ms ease-out;
}

.title-bar .controls .close{position:relative;
box-sizing:border-box;width:21px;height:21px;
padding:0;border:1px solid #6696eb;
border-radius:3px;background-image:
linear-gradient(180deg,#e8795f,#e45f40 30%,
#e45d3d 52%,#e2552a 80%,#ae3110);
transition:filter 60ms ease-out}

The gap is the whole story. JS shrinks 44% because a minifier can rename things: every local variable collapses to one letter, information genuinely leaves the file. CSS shrinks 15% because nothing in it is renamable: selectors and properties are the page's public API, so all a CSS minifier can remove is whitespace, comments, and micro-slack (note it dropped the redundant 0% and 100% gradient stops). And whitespace is exactly the thing brotli already compresses to almost nothing.

So the real question is never "does the file get smaller" but "does the WIRE get smaller after brotli." This site's CSS lives in four habitats, and I measured all four:

The knobs are part of the contract

“Minify it” is not one switch. The useful part of today's work was deciding which transformations are safe for this site, which are intentionally absent, and where a warning becomes a failed deploy. The two panels below are the actual policy behind build.mjs, not a menu of hypothetical optimizations.

Making s-maxage true

The second shipment in this batch fixed a quieter embarrassment. Worker-rendered pages here sent s-maxage=300, and the edge ignored it: Cloudflare does not automatically cache worker output, so cf-cache-status read none and the header was decorative. Every visit to /lens re-assembled a byte-identical shell; every visit to /writing re-fetched every post's text just to print character counts.

The fix is the Workers Cache API, caches.default: on miss, render and store; on hit, serve from the colo. Three rules carried over from this site's scar tissue: only status 200 is ever stored (this site once served homepage HTML at thumbnail URLs with a year-long cache header, and does not repeat mistakes it has written down), TTLs stay short and honest because deploys do NOT flush this cache, and every response says which path it took in an x-edge-cache header. The reading page also dropped its no-store (it was conservatism, not necessity), and the manual refresh hook evicts the edge copy too, so a bust still busts.

The honest scorecard