TLS time is pure overhead: it happens before the first byte of content and it happens again for every client whose connection wasn't reused or resumed. On a well-run edge the handshake costs one round trip; on a neglected one it can cost three, plus a side-trip to a certificate authority you've never heard of. The difference is configuration, and all of it lives at the CDN layer where you can fix it in an afternoon.
Why the handshake shows up in your metrics
Your real-user data records connection setup inside time-to-first-byte, which is why TLS problems masquerade as "slow server" (see the TTFB guide for splitting that apart). The tax is regressive: it lands hardest on exactly the users who are already slow — long-RTT and mobile connections pay the most per round trip — and on session patterns with many short visits, where connections rarely live long enough to amortize their setup. Before tuning, get a baseline: the handshake segment is visible in any browser DevTools timing breakdown and in synthetic tests, per connection, per geography.
TLS 1.3 and resumption: the settings
TLS 1.3 cuts the full handshake from two round trips to one and should be enabled with 1.2 kept as the floor for legacy clients; anything older has no business on a public edge in 2026. Resumption then lets a returning client skip most of the handshake entirely, via session tickets. Two things to verify rather than assume: that resumption is actually enabled on your edge configuration, and that it works across the provider's points of presence rather than only per-machine — a ticket that is only honoured by the exact server that issued it resumes almost nothing on a large anycast edge. Your provider's documentation will say; a synthetic test that reconnects and reports "session reused" will prove. On the cipher side, modern defaults are fine — the win in 2026 is not cipher golf, it is making sure nothing forces a downgrade to 1.2 full handshakes for capable clients.
0-RTT: when to allow it
TLS 1.3 and QUIC both offer 0-RTT: a resuming client sends its first request in the same flight as the resumption itself, spending zero round trips on setup. The catch is replay: a network attacker can capture and re-send that early data, so 0-RTT is only safe for requests where a replay is harmless. The workable policy is to enable it for GET-heavy static and page traffic and keep it off — or have the edge reject early data — for APIs and anything non-idempotent. Some platforms expose this as a per-property switch, some handle the method restriction for you; find out which yours does before enabling, and write the decision down, because the next person to look at this setting will not know why it is half-on.
OCSP stapling and revocation checks
When a browser checks whether your certificate has been revoked, the slow path is a live OCSP query to the certificate authority — a third-party lookup on your critical path, from the client, to infrastructure you don't control. Stapling fixes this: the edge fetches the signed OCSP response itself, caches it, and attaches ("staples") it to the handshake, so the client never makes the side-trip. Most major CDNs staple by default on their managed certificates, but verify it — openssl s_client -status against your hostname shows whether an OCSP response is included. The ecosystem is also moving to shorter-lived certificates that reduce how much revocation checking matters at all, which is one more reason to let the CDN manage issuance and renewal rather than uploading certificates by hand: automated renewal is what makes short lifetimes operationally free.
The certificate-chain audit
Every certificate in your chain is bytes in the handshake, and a misconfigured chain is worse than a long one: if the server omits an intermediate, some clients fetch it themselves mid-handshake (another third-party side-trip) and others simply fail. The audit takes ten minutes: pull the served chain with openssl s_client -showcerts, confirm it is complete and in order, contains no expired or self-signed extras, and is as short as the CA allows. Cross-signed legacy intermediates that were needed for ancient clients are still being served by sites that added them in a panic years ago and never removed them. Do the audit per CDN if you run several — each edge serves its own chain — and fold the whole checklist into the quarterly review alongside the security baseline, then re-check the handshake segment in the field data to bank the improvement, ideally after HTTP/3 is live so resumption gains compound with QUIC's.