Performance
TLS handshake
TLS handshake is the exchange of messages between browser and server that sets up an encrypted HTTPS connection. It happens before the first byte of HTML can be requested.
How it is measured
In the Network panel's Timing tab it appears as the SSL segment. In code, `connectEnd - secureConnectionStart` from Resource Timing gives its duration. TLS 1.3 needs one round trip and TLS 1.2 needs two, and a returning visitor can resume a session and skip some of the work.
Handshake time scales with round-trip time and certificate chain size. On a 120 ms mobile connection, TLS 1.2 costs about 240 ms and TLS 1.3 about 120 ms. Check the protocol with `openssl s_client` or your CDN's TLS settings.
Worked example
A boutique hotel's site sits on an old origin in Singapore that offers only TLS 1.2 and sends a 4 KB certificate chain. Visitors from Sydney, at 95 ms RTT, see an SSL segment of 310 ms.
Moving DNS to a CDN with TLS 1.3 and OCSP stapling terminates TLS in Sydney, so the SSL segment shrinks to 38 ms and TTFB falls from 980 ms to 540 ms.
How it differs
A TLS handshake is one slice of what time to first byte includes. TTFB also covers redirects, DNS, TCP, and server processing. HTTP/3 over QUIC folds transport and crypto setup into fewer round trips, which reduces the handshake cost and the TTFB it feeds.
Common errors
Testing from near the server. Ignoring redirects from http to https to www, each with its own handshake. Serving a long certificate chain. Leaving TLS 1.0 and 1.1 enabled. Missing OCSP stapling. Forgetting that every extra host needs its own handshake.
In practice
Run a Timing-tab check on your homepage from a distant region. If SSL is over 150 ms, put a CDN in front, enable TLS 1.3, and remove redirect hops. Make sure the apex domain redirects to the final host in a single step.