Keeping this website under ten kilobytes
The median web page today ships roughly two megabytes. This page — text, layout, dark-mode colours and all — is under ten kilobytes, smaller than many favicons. That is not an accident, and it did not require heroics. It required deleting things.
What I cut
- Web fonts. The system stack (SF, Segoe, Roboto) already sits on the device and renders instantly. A webfont trades that for an extra round trip and a flash of the wrong typeface.
- JavaScript. There is none. Nothing on a site like this needs it, and every kilobyte of it has to be downloaded, parsed and executed on somebody's phone.
- Images. The only "image" is a two-shape SVG favicon inlined as a data URI, so the browser does not even open a second request for it.
- A build pipeline. The HTML is hand-written. What you can read, you can fix.
One request per page
Each page carries its own ~1.4 KB of CSS in the head instead of linking a stylesheet. On a big site you would factor that out and let the cache do its work. At this size the arithmetic flips: the first visit is the one that feels slow, and inline styles mean the very first request already contains everything needed to render. Repeat visits are cheap either way — the whole site fits in a fraction of one news site's tracking script.
Pre-compressed, not compressed-on-demand
The server ships each page as .zst, .br and
.gz siblings and sends the best one your browser accepts,
straight off disk. Zero compression CPU per request — kind to the little VPS
this runs on.
Measure, don't guess
curl -s -o /dev/null -w '%{size_download} bytes\n' https://example.com/Hotel Wi-Fi, a train connection, a ten-year-old phone: the page is simply there. It also renders fine in lynx. Respecting readers' bandwidth, it turns out, is mostly a matter of not shipping things nobody asked for.