Why the First Kilobytes Are the Slow Ones

Start at the slow and you miss it. Start at the surprise and you miss how it arrived. The bug lived in the hand-off.

I have lost on-call weeks to this exact shape of slow burn, so the order below is the order I fix it in.

This is the anatomy of the congestion window ramp, and of the specific property that makes bandwidth the wrong lever: a new connection cannot use the available bandwidth until the window has grown, and the growth costs round trips, so the first response is latency-bound rather than throughput-bound.

This applies to every TCP connection, and the mechanism is the congestion control algorithm, which is the same regardless of the application.

Why the window starts small

The sender does not know the path, and the not knowing is the capacity, and the capacity is the unknown, and the unknown is the probe, and the probe is the small send, and the small send is the ten packets, and the ten is the initial window, and the window is the guess, and the guess is the conservative, and the conservative is the network's protection, and the protection is the reason the ramp exists.

The doubling is the growth, and the growth is the exponential, and the exponential is the fast in the round trips and the slow in the absolute, and the absolute is the latency times the count, and the count is the log of the size, and the log is the ramp's length, and the length is the first response's delay, and the delay is the user's wait.

The bandwidth is the pipe's width, and the width is the irrelevant until the window fills it, and the fills is the growth, and the growth is the round trips, and the round trips are the distance, and the distance is the speed of light, and the speed of light is the floor, and the floor is the reason the fat pipe does not fix the first load.

Why the connection reuse matters

The window is the connection's, and the connection's is the discarded at the close, and the close is the reset, and the reset is the new connection, and the new connection is the ten packets again, and the again is the ramp, and the ramp is the slow, and the slow is the reason the keep-alive matters, and the matters is the reuse, and the reuse is the grown window, and the grown is the fast.

The connection pool is the reuse, and the reuse is the warm, and the warm is the window's persistence, and the persistence is the speed, and the speed is the fix, and the fix is the pool, and the pool is the configuration, and the configuration is the discipline, because the cold connection pays the ramp every time.

This is the same shape as the TLS handshake that cost three round trips, same mechanism, different costume.

What to do about it

Fit the critical response in the initial window. The ten packets is the about fourteen kilobytes, and the fourteen is the budget, and the budget is the above-the-fold's HTML, and the HTML is the inline, and the inline is the one round trip, and the round trip is the fast, and the fast is the fix, and the fix is the size discipline, because the response that fits the window needs no growth.

Keep the connections warm. The keep-alive is the reuse, and the reuse is the grown window, and the grown is the no ramp, and the no ramp is the fix, and the fix is the pool, and the pool is the server's and the client's, and the two are the configuration, and the configuration is the discipline.

Preconnect before the request is needed. The preconnect is the early handshake, and the handshake is the ramp's start, and the start is the overlap, and the overlap is the hidden cost, and the hidden is the fix, and the fix is the hint, and the hint is the one line in the head.

Do not buy bandwidth to fix the first load. The bandwidth is the throughput, and the throughput is the irrelevant during the ramp, and the ramp is the latency, and the latency is the round trips, and the round trips are the geography, and the geography is the fix's constraint, and the constraint is the edge, and the edge is the closer server, and the closer is the fewer milliseconds.

Measure the time to first byte, not the throughput. The first byte is the ramp plus the handshake, and the two are the setup, and the setup is the user's wait, and the wait is the metric, and the metric is the fix's target, and the target is the reason the throughput number looks fine while the page feels slow.

The takeaway

A new TCP connection starts with a small congestion window and doubles it per round trip, so the first response is limited by the ramp rather than by the available bandwidth. Fit the critical response in the initial window, keep connections warm, preconnect early, reduce the round trip time rather than buying bandwidth, and measure time to first byte.

The page was slow on the first load and fast on the second, and the connection was the same speed both times, because the first paid the congestion window ramp from ten packets while the second reused a connection whose window had already grown. That is the whole pattern, and it is the part worth remembering.

Published on debugly.dev by Rohit Bhadani | Founder of Krova Cloud