FastBlog
← All posts

The 14 kB rule, and why your first packet matters

Your server can be quick and your page can still feel slow. The first round trip is the one that decides.

·last month ·3 min read ·587 words

There is a number that quietly decides how quickly your page starts to appear, and it has almost nothing to do with how fast your server is. It is about fourteen kilobytes.

When a browser opens a connection, it does not immediately push data at full speed. TCP starts cautiously: it sends a small burst, waits for the acknowledgements to come back, then roughly doubles what it is willing to send. This is slow start, and on most modern stacks the initial congestion window is ten packets. Ten packets at around 1,460 usable bytes each comes to a little over fourteen kilobytes. Whatever fits inside that window arrives in the first round trip. Everything after it waits for the next one.

On a wired connection a round trip might be fifteen milliseconds and nobody notices. On a phone clinging to one bar of signal, a round trip can be three hundred. At that point the gap between a 13 kB response and a 45 kB response is not "a few kilobytes" — it is two or three extra waits before the browser has enough markup to paint anything at all.

The rule is about order, not size

It is tempting to read this as make every page smaller than fourteen kilobytes. Most real pages cannot be, and chasing that target will only make you miserable. The useful version of the rule is about what you put first.

The browser reads your HTML from the top and acts on it as it arrives. If the first fourteen kilobytes contain a complete, styled, readable header and the opening of your content, the page is visibly alive after a single round trip. If the first fourteen kilobytes are a render-blocking stylesheet link, three script tags and a preamble of empty wrapper elements, the reader gets a white screen while the connection warms up.

So the questions worth asking are ordering questions:

  • Does the CSS needed for the top of the page live in the document, or behind another request?
  • Is anything in the <head> blocking the parser without earning it?
  • How many bytes of markup come before the first word the reader actually wants?
  • Is compression on? Fourteen kilobytes is fourteen kilobytes on the wire, after gzip or brotli — which for typical HTML means something like forty to sixty kilobytes of source.

That last point is the one people miss most often, and it is good news. You have far more room than the raw number suggests.

Measuring it

You do not need a lab. Ask for the page the way a browser would, and look at what actually came down the wire:

curl -s -o /dev/null \
  -H 'Accept-Encoding: gzip, br' \
  -w 'transferred: %{size_download} bytes in %{time_total}s\n' \
  https://example.com/

Then throttle a real browser to a slow connection with a few hundred milliseconds of added latency and watch when the first paint happens. The waterfall will tell you honestly whether your first packet is doing useful work or carrying furniture.

Why it is still true

HTTP/2 and HTTP/3 changed how requests are multiplexed, not how congestion control ramps up. QUIC still starts conservatively. TLS still costs a handshake before any of your bytes move. The initial window has crept upward on some stacks and there is ongoing work to raise it further, but the shape of the problem has not changed: the first response is the cheapest set of bytes you will ever send, and most sites spend them on scaffolding.

Spend them on something the reader can see.

Related reading