Slow start is not slow
Slow start grows the congestion window exponentially — roughly doubling every round trip — until it hits the slow-start threshold or a loss occurs. What is slow is the starting point, not the growth rate.
The practical consequence is that short connections never leave it. A transfer of a few tens of kilobytes finishes entirely inside slow start, so its throughput is governed by round-trip time and the initial window, not by the bandwidth available. Buying a fatter pipe changes nothing for it.
Work it through: with an initial window of 10 segments and roughly 1460 bytes per segment, the first round trip moves about 14 KB, the second about 29 KB, the third about 58 KB. A 100 KB response takes four round trips no matter how much bandwidth sits idle underneath. At 150 ms RTT that is 600 ms of pure latency, and not one millisecond of it is a bandwidth problem.
Why this matters more than bandwidth
It is the reason connection reuse dominates small-transfer performance, and the reason HTTP keep-alive and connection pooling are not micro-optimisations. It is also why raising the initial window from 3 to 10 segments (RFC 6928) was worth standardising: for the overwhelmingly common case of a small response, it removes an entire round trip.
When someone reports that a service is slow and the server-side latency numbers look fine, count the round trips before looking at anything else.