I shipped a working landing page in 14 KB — source summary
A dev.to article (by "thegdsks", May 2026) on radical web-performance minimalism.
Delivered via Telegram, ingested 2026-05-29. Text in raw/landing-page-14kb.md.
What it argues
- Frames the bloat problem: the median 2025 web page weighs ~2,600 KB (desktop), while a demoscene coder shipped a working 256-byte ZX Spectrum intro. "The 2026 web page is the same size as a 1996 SimCity install, minus the cities, plus a cookie banner."
- Goal: the floor for a usable, production-grade landing page (headline, value prop, three feature blocks, form, footer, analytics; accessible, decent typography).
- Result: 14 KB total over the wire — one TCP slow-start window, rendering in <50 ms on a midrange Android.
- Byte budget: HTML 4 KB, CSS 3 KB, JS 0 KB, web fonts 0 KB (system fonts), images 6 KB (inline SVG). Walks through it "line by line."
Migrated from the research-wiki into this dedicated web-performance wiki (2026-05-29) — the first source here. See synthesis for the working thesis.
Why this is T2 (re-tiered 2026-08-28)
Graded T4 on the masthead — a dev.to post. What it rests on is the author building the artifact and measuring every byte of it, layer by layer, which is the T2 bucket ("someone tested, measured…the thing"). The HTTP Archive median it argues against is a T1 figure the author cites rather than asserts.
Recovered by the recall probe (2026-08-30)
The [[../research-wiki/wicer|WiCER]]-style probe built this day found two things in this raw document that no webperf page carried, and the first is the mechanism the whole page rests on.
Why 14 KB, exactly. The page's headline number was here as a target and never as an explanation. The source gives it: on a new TCP connection slow start lets the server send roughly ten packets before it must wait for an acknowledgement, and ten packets at about 1,460 bytes each after headers is the "first 14 KB" window. Fit the above-the-fold critical path inside it and the browser renders meaningful content in one round trip; miss it and you pay another RTT per additional 14 KB. On a 100 ms mobile connection the author puts three round trips at 100 ms versus 400 ms to first paint. He also anticipates the objection — the "14 KB rule" circulates as folklore — and points at web.dev, Chrome devrel teaching material and the HTTP Archive annual report as using the same number.
Where the bytes actually are, from the author's own measurements across "a few dozen popular landing pages," 2026:
| Layer | Median KB | Share |
|---|---|---|
| Images | 1,400 | 54% |
| JavaScript | 580 | 22% |
| Fonts | 220 | 8% |
| CSS | 180 | 7% |
| Video previews | 140 | 5% |
| HTML | 60 | 2% |
| Analytics + ads | 60 | 2% |
| Total | 2,640 | 100% |
Self-measured and self-reported, with the sample described only as "a few dozen" — so it is an author's audit, not a census, and web-almanac-page-weight-2025 remains the source of record for population figures. Its value is the shape: images and JavaScript are 76% of the weight, which is where a budget has to bite. See page-weight and performance-budget.
Still self-reported: no public URL for the finished page is given here, so the 14 KB is the author's own audit of their own work and nobody has re-weighed it. That is the caveat, and it is a different objection from "a personal blog wrote it."