Why your website should be under 14kB in size

A page that fits into roughly 14 kilobytes can load noticeably faster than a slightly larger one—often by hundreds of milliseconds—because TCP’s slow start ramps up sending conservatively at the start of a connection. The practical takeaway is simple: if the first request’s “critical” bytes (headers included) land within the first TCP window, browsers can begin rendering sooner, especially on high-latency or lossy networks.

The mechanism starts with how TCP works over IP. IP moves packets but doesn’t confirm delivery or track ports; TCP adds reliability by using acknowledgements. After a browser opens a connection and sends an HTTP request, the server doesn’t know the available bandwidth between the two endpoints. So TCP slow start begins with a small burst—commonly 10 TCP packets—then doubles the amount sent after acknowledgements arrive. If packets are lost or acknowledgements don’t return, the server backs off and sends more slowly. That “start small, then ramp” behavior is why tiny differences in total bytes can matter early in the load.

Where the 14 KB number comes from: Ethernet’s typical maximum transmission unit is about 1500 bytes. With TCP and IP headers consuming about 40 bytes total per packet (16 bytes for IP and 24 bytes for TCP), the payload per packet is about 1460 bytes. Multiply that by the initial slow-start packet count (often 10) and you land near 14,600 bytes—about 14 KB. The rule therefore isn’t just about the HTML body; it includes TCP/HTTP headers, which are uncompressed, and it’s meant for the first response that must be useful immediately.

Latency turns that early ramp into real user-perceived delay. Each TCP slow-start step depends on round trips: the browser must receive packets and send acknowledgements back before the server can send more. On satellite links, a single round trip can be on the order of hundreds of milliseconds. The transcript walks through a geostationary-style example: Earth-to-satellite and back adds roughly 120 ms each way, plus additional time to reach the server and return, plus processing. The resulting estimate lands around 612 ms per round trip, and HTTPS can add extra round trips before the first real payload. If a page requires multiple round trips to fetch its first resources, those delays compound.

That’s why the “14 KB rule” is treated as a performance target rather than a magic law. It’s most valuable when networks are slow, mobile, congested, or lossy—conditions that trigger packet loss and force additional retransmissions and round trips. The recommended strategy is to keep the first ~14 KB of the initial response capable of rendering something useful: critical CSS/JS and meaningful above-the-fold content, while deferring heavier assets. Compression (like gzip) can help pack more uncompressed content into the 14 KB budget, but base64-embedding images into HTML can bloat the payload.

The discussion also notes caveats: TCP slow start behavior varies by server and can start with more than 10 packets in some cases, and modern protocols like HTTP/2 and HTTP/3 don’t automatically eliminate the underlying “start conservatively” problem. Still, the core message holds: optimizing the first bytes matters, because TCP’s early ramp and round-trip latency determine how quickly a page becomes interactive.