Perfnode · field instrument 01

Where your first round trip runs out

Nine documents, all exactly 60 kB. The only difference between them is how far into the HTML the image tag sits. If TCP slow start behaves the way the textbooks say, the time it takes your browser to discover that image will not rise smoothly across the nine — it will sit flat, jump by one full round trip, and sit flat again.

Idle — nothing measured yet
Image discovery delay against byte offset in the document
Your connection (median) Predicted flight boundary, initcwnd 10 Vertical marks = spread across samples

No data yet

The run opens each of the nine documents on its own hostname, several times over, and discards any load that landed on a reused connection. Takes about a minute.

What this is measuring

A server does not put an entire response on the wire at once. It sends an initial burst, waits for acknowledgement, then sends a larger one. On Linux that first burst defaults to ten segments — roughly 14.6 kB — so anything referenced past that point cannot be seen by the browser's preload scanner until a further round trip has completed.

The usual advice drawn from this is to keep your page under 14 kB, which is rarely achievable. The measurement here points somewhere more useful: the document size never changes, so if the curve steps, what matters is the position of the reference, not the weight of the page.

Why the delay is shown in round trips
Your absolute numbers depend on how far you sit from the server. Dividing by your own TCP handshake time removes that, so a step of exactly 1.0 means one extra round trip and nothing else.
Why each offset has its own hostname
The boundary only exists on a fresh connection. Loading all nine over one socket would measure a congestion window that has already grown, and the step would vanish.
Why some samples get thrown away
Proxies, VPNs and corporate middleboxes can quietly reuse connections or downgrade the protocol. Those loads are detected and dropped rather than averaged in.
What this cannot show you
That the congestion window is the cause. Proving that means changing initcwnd on the server and watching the step move — which needs the Docker harness in the repository, not this page.