TCP Slow Start: Why the First 14 KB of Your Page Matter

Short answer: When a browser opens a new connection, the server does not send data at full speed. TCP slow start lets it send only about ten packets, roughly 14 KB, before it must wait for the browser to confirm receipt, and the allowance then grows with each round trip. If the first 14 KB of your compressed HTML contain the head of the page and the first content, the browser can start drawing sooner. Keeping that opening small and well ordered is a cheap speed gain.

What slow start is

The internet is shared by billions of devices, and a server cannot know how much data the path to a visitor can carry. If it sent everything at once, routers on the way would overflow and drop packets, and the resulting retransmissions would make things slower for everyone. TCP, the protocol under HTTP/1.1 and HTTP/2, therefore starts carefully. It sends a small burst, waits for acknowledgements, and for every acknowledgement it allows itself to send more. In the early stage the allowance roughly doubles with each round trip, which is why the method is called slow start even though growth is exponential.

The size of the first burst is called the initial congestion window. Modern servers commonly use ten segments. A segment usually carries up to about 1,460 bytes of data, so ten segments are around 14,600 bytes, which is where the figure of 14 KB comes from. Exact numbers depend on the server settings and the network, but the order of magnitude is the same.

Why it matters for a web page

Before a page can appear, the browser must receive the HTML and read it from the top. After the DNS lookup, the connection and the TLS handshake, which are covered in the article on TLS session resumption, the first request goes out. The server answers with the first window of data, about 14 KB. If the HTML is larger, the rest has to wait for the next round trips: 14 KB, then roughly 28 KB, then 56 KB, and so on. On a mobile connection with a round trip of 100 milliseconds, each extra trip adds a visible delay.

This means a page whose useful opening fits inside the first window can begin to render a whole round trip earlier than one that needs the second window to reach the important part. The effect is small for a fast fibre connection and larger for slow or distant visitors, who are the ones most likely to give up.

Compressed size is what counts

The 14 KB limit applies to bytes on the wire, so it concerns the compressed response. HTML compresses very well, often to a quarter of its size or less. A page with 60 KB of HTML may therefore need only 14 KB after compression, and fit almost entirely in the first window. This is one more reason to make sure that compression is on; the comparison of gzip and Brotli explains the options. Check the response headers of your page, and if there is no content encoding, turn compression on before you do anything else.

Images, scripts and style sheets are separate requests, so they do not count toward the HTML window, but they have their own slow start on any new connection. That is a reason to reuse connections and to avoid spreading resources over many domains.

What to put early in the HTML

The browser needs the head of the document first, because it contains the title, the character set, the viewport and links to style sheets and scripts. Keep this part lean and ordered:

Put the character set and the viewport declarations first.
Place a small amount of critical CSS inline, so that the first view can be drawn without waiting for a style sheet. The guide to critical CSS shows how to choose it.
Link the full style sheet once, and avoid long chains of imports.
Load scripts with defer or async, as described in defer and async, so that they do not block the parser.
Avoid large inline blobs in the head, such as huge JSON data or inline SVG sprites, which push the visible content to later windows.

The body should then start with the content that matters most: the main heading, the first paragraph and the main image, rather than a large navigation with dozens of links or a big block of tracking code.

Common things that bloat the opening

Page builders and themes that print big inline style blocks and many wrapper elements before the content.
Inline scripts from tag managers, analytics and chat widgets placed at the top of the head.
Mega menus with hundreds of links rendered in HTML before the main content.
Base64 images inlined into HTML or CSS, which are large and do not cache separately.
Long comments and whitespace, which minification would remove, see minifying CSS and JavaScript.

Trimming these does more than save bytes; it also gets the main content closer to the top of the document, which helps the largest contentful paint. The guide to improving largest contentful paint covers the related techniques.

Consider two pages that both reach 120 KB of raw HTML. The first is a news article whose HTML starts with a 30 KB menu, then 20 KB of inline styles, and only then the headline. The second begins with a 3 KB head, a small block of critical styles and the headline, and keeps the menu and the footer for the end. After compression both might be near 30 KB, which needs a second window. In the first, the headline sits in the second window, so nothing meaningful can be drawn until that arrives. In the second, the headline is already in the first window and appears a full round trip earlier. The page weight is the same, yet the visitor experience differs, which shows why the order of the document matters as much as its size.

Other ways to soften slow start

Reuse connections. A warm connection has already grown its window. HTTP/2 puts many requests on one connection, see HTTP/2 and HTTP/3.
Serve from a nearby place. A shorter round trip makes each step of growth faster. A content delivery network helps, as the article on whether you need a CDN explains.
Keep the server fast. The first byte must arrive before any window opens, so work on server response time too.
Use a modern protocol. HTTP/3 runs on QUIC instead of TCP, with its own congestion control and a faster handshake, although the same principle of starting small applies.

Some providers raise the initial window above ten segments on their own servers. That is a tuning option for people who manage their servers, but it comes with a risk of congestion for some networks, so leave it at the default unless you can test the effect for real visitors.

How to test your own page

Open the developer tools of your browser, load the page and look at the network panel for the HTML document. Note the transferred size, which is the compressed size, and the time to receive it. If the transferred size is under about 14 KB, the whole document fits in one window. If it is 60 KB, expect several trips. Throttle the network to a slow mobile profile to see the difference more clearly. A waterfall chart shows the time spent waiting and receiving; the article on reading a waterfall chart explains how to interpret it.

Do not chase the number blindly. A page of 20 KB that is slow for another reason, such as a heavy script, will not become fast by saving 6 KB. Treat the 14 KB figure as a guide for the order of the document, not as a strict budget.

A quick audit of the whole picture

Slow start is one factor among many in the time before a page appears. Run a free check with Site AI Audit to see your mobile speed, server response time and compression in one report, and find the larger problems first.

The bottom line

New connections start with a small allowance, about ten packets or 14 KB. Compress your HTML, keep the head lean and put the content that matters near the top, so that the first screen does not wait for extra round trips. It is a small change that helps the people on the slowest connections the most.

الأسئلة الشائعة

Is 14 KB an exact limit?

No. It follows from ten segments of about 1,460 bytes, and servers and networks differ. Treat it as a rough guide.

Does the limit apply to the uncompressed or the compressed page?

To the compressed page, since compression happens before the data is sent. This is why enabling gzip or Brotli matters.

Does HTTP/2 remove slow start?

No. HTTP/2 runs over TCP and still starts with a small window, but it reuses one connection for many requests, so the cost is paid less often.

Will this change my Google ranking?

Not directly. The benefit comes from faster rendering, which can improve the page experience metrics and the behaviour of visitors on slow connections.

Should I inline all my CSS to stay under 14 KB?

No. Inline only the small part needed for the first screen and load the rest normally, otherwise the HTML grows and cannot be cached separately.