Learning objective. Collect the deterministic ways to cut effective latency (0-RTT for safe requests, warm-connection reuse, 0.5-RTT and Early Hints, coalescing, and avoiding a Retry), and see why each is a guaranteed win rather than a speculative bet that can waste bandwidth.
Deterministic wins vs. speculation #
There are two ways to make a page feel faster. One is to speculate: guess what the client will need and send it early (HTTP/2 server push, aggressive preloading, prefetching links the user might click). Speculation wins when the guess is right and wastes bandwidth, cache space, and congestion-window room when it is wrong. On a long-RTT path, the wasted bytes compete with the data the client actually asked for, sometimes making things slower. The other way is to remove round trips and overlaps that are certain: savings that never send a byte the client didn't need. This section is the second kind. (Server push is deliberately absent; it is disabled by default in practice and superseded by the non-speculative Early Hints below.)
The savings, in order of impact #
Reuse a warm connection. The single biggest deterministic win is not opening a new connection at all. An established connection has already paid its handshake RTT, so a request on it reaches first byte in ~1 RTT instead of ~2 (§8.1). Connection pooling and HTTP/3's connection coalescing (reusing one connection for multiple origins that share a certificate) turn many would-be handshakes into zero. Keepalive (§7.3) keeps the connection warm through lulls so it is still there when the next request comes.
0-RTT for safe requests. When a new connection is unavoidable, 0-RTT sends the request as TLS early data in the first flight, saving the handshake round trip (§8.1, §2.3). The constraint is the point: early data is replayable, and QUIC puts the responsibility on the application protocol, which "MUST describe how the protocol uses 0-RTT" and restrict it to requests safe to process more than once ([RFC 9001 §9.2]): GETs and other idempotent requests, not a payment. Used within that rule, 0-RTT is not speculation; it is a real request sent one round trip earlier.
0.5-RTT server data. The server can begin sending response data in 1-RTT packets before the handshake fully completes ([RFC 9000 §7.1]) — "0.5-RTT data." It shaves part of a round trip off the response with no risk, because the server is answering a request it has already received.
Early Hints (103). To let a client fetch a page's sub-resources without waiting for the main response, the server sends an interim 103 Early Hints response naming them (§5.3): an authoritative statement of what the page links, not a guess about what the user wants. The client fetches those assets a round trip early, on the same connection. This is the non-speculative replacement for server push: the server still decides what to surface early, but the client does the fetching, so nothing is sent that the client won't use.
Coalescing and full flights. Packing multiple QUIC packets into one datagram (§8.1) and keeping the congestion window filled both reduce round trips indirectly: the first by cutting datagram count, the second by making losses detectable via the packet threshold rather than a slow PTO (§8.2).
Avoiding the round trips you can #
Some latency is added by avoidable protocol events:
- A Retry costs a full RTT. Address-validation Retry adds a round trip ([RFC 9000 §8.1.2]). Servers that don't need per-connection address validation (or that use it selectively, only under load) spare every client that extra RTT.
- The amplification limit can stall the handshake. Before validating the client's address, a server may send no more than three times the bytes it received ([RFC 9000 §8.1]). If the server's first flight (ServerHello + certificate) exceeds 3× a small client Initial, it must wait for more client data: an extra round trip. The client's side of the fix is already mandatory: padding Initial datagrams to 1200 bytes raises the server's budget ([RFC 9000 §8.1]); the server's side is keeping its certificate chain small.
Worked example: a page load on a reused connection #
Figure 8.3-1 stacks the savings. The client already holds a warm connection, so there is no
handshake RTT to pay. It sends GET /page as 0-RTT early data. The server, not yet finished
rendering, replies with 103 Early Hints listing /style.css and /app.js (assets it knows
the page needs), and the client immediately opens concurrent streams for them. The server then
streams the main response as 0.5-RTT data and the three 200s follow. Compared with a cold
connection that fetched assets only after parsing the main response, this removes the handshake
round trip, the request round trip, and the discover-assets round trip — three deterministic RTTs,
none of them a gamble.
The line between deterministic and speculative is who benefits when you're wrong. Early Hints and 0-RTT can be "wrong" (the client might already have the asset cached, the 0-RTT request might be retried), but the cost is bounded and the mechanisms are designed for it (the client skips assets it has; 0-RTT is limited to replay-safe requests). Server push and blind prefetch are speculative because a wrong guess sends bytes nobody uses, and on a long path those bytes directly delay the ones that matter. Prefer mechanisms whose failure mode is "no worse than not doing it."
editorial Rank these by leverage for your traffic. For an API client, warm-connection reuse and 0-RTT on idempotent calls are almost the whole game — pool aggressively and keep connections alive. For a web page, add 103 Early Hints for the critical CSS/JS and keep the certificate chain small so the amplification limit never stalls the handshake. Resist re-enabling server push or bolting on broad prefetch to "save a round trip"; measure first, because on the long paths where a round trip is expensive, speculative bytes are also expensive, and the deterministic wins here capture most of the benefit with none of the waste.
Takeaways #
Effective latency drops most from certain savings: reusing a warm connection to skip the handshake RTT, 0-RTT for replay-safe requests, 0.5-RTT server data, and 103 Early Hints to fetch known assets a round trip early, plus avoiding an address-validation Retry and keeping the server's first flight under the amplification limit. Each is a guaranteed win, never a speculative byte. How many streams to run concurrently to use the round trips you've saved (sizing to the bandwidth-delay product) is §8.4.