Transport tuning for high-latency audiences
Most transport tuning is aimed at the wrong cost. Four changes that survived review across member traffic, and the conditions where they stop paying off.
- Transport & protocol workstream
- 8 minutes
- Transport & protocolLatency
Where the latency is actually spent
Handshake and DNS resolution dominate the first byte for a cold connection; retransmission dominates everything after it. Most tuning effort goes at the second problem while the first sits in a cached resolver configuration nobody has revisited.
Four changes that survived review
- Keep the connection warm. Persistent connections with a sane keep-alive window remove most setup cost for repeat viewers. The largest gains came on mobile networks with high round-trip times.
- Set a congestion window you can justify. Aggressive initial windows help short flows and hurt when many sessions start at once. Test at your own peak, not in a lab.
- Treat retransmission as a symptom. A rising retransmission rate on a stable path is usually receiver buffering or pacing, not the path itself.
- Stop prefetching blind. Speculative fetches multiply setup cost on congested links and add bytes nobody consumed.
Conditions where these stop paying off
On paths under roughly 30 ms round-trip the setup cost is small enough that other work dominates. If your traffic is concentrated in a single metro, start with delivery and caching instead.
What to measure
Time to first byte by connection state (cold and warm), retransmission ratio by hour, and the share of bytes fetched but never rendered. Report all three — any one alone will mislead you.