TLS 1.3 cut the handshake from two round trips to one and rebuilt resumption around a cleaner mechanism. At CDN scale those round trips are the visible part of your TTFB in every far-flung geography, which makes the protocol details a performance topic, not just a security one.
The full handshake, one round trip
A 1.3 client sends its key share optimistically in the first flight; the server answers with its own share plus certificate, and encrypted application data flows on the next packet. Compared to 1.2’s two round trips, a Sydney user talking to a Sydney edge saves a handful of milliseconds; the same user reaching an unshielded distant origin saves a continent’s worth. Edge TLS termination plus 1.3 is precisely why connection setup stopped dominating waterfalls.
Resumption and PSK
1.3 replaced the old session-ID and session-ticket machinery with pre-shared keys delivered via NewSessionTicket: returning clients resume in one round trip with fresh keys. At CDN scale the operational question is ticket-key management across thousands of edge nodes, rotated aggressively and shared correctly, because resumption rates directly move your handshake-latency distribution, and a fleet that cannot resume across POPs quietly downgrades your repeat visitors to full handshakes.
A measurement note that keeps teams honest: handshake improvements concentrate at the connection level, so their visibility depends on connection reuse patterns. A browser session multiplexing everything over one warm HTTP/2 connection pays handshake cost once, so 1.3’s savings show up in first-visit and long-tail metrics rather than medians. RUM percentile splits by navigation type, first visit versus repeat, versus session depth, reveal the true footprint. Teams that look only at median TTFB conclude TLS work is done; the p95 of cold connections in distant geographies usually disagrees, and it is exactly the cohort edge termination exists to serve.
0-RTT, honestly
Zero round-trip resumption lets a returning client send application data in its very first packet. The catch is structural: 0-RTT data is replayable, an attacker can capture and resend it, so it is safe only for idempotent requests. CDNs therefore restrict early data to GETs without side effects, and your application must treat anything arriving over 0-RTT as potentially replayed. The win is real, first-byte before the handshake completes, and it belongs on cacheable GET traffic, never on your checkout POST.
In practice
Confirm 1.3 is negotiated for the overwhelming share of your traffic (per-protocol analytics again), check resumption rates if your provider exposes them, and enable 0-RTT only with the replay constraints understood and enforced. Then stop: the remaining TLS milliseconds are certificate-chain size and OCSP behavior, which are their own article, and smaller wins than getting these three right.
Protocol posture is a standing line in our provider benchmarks, resumption rates and 0-RTT policy included.