The Encryption Overhead That Enables Everything Else
HTTPS encrypts the connection between a visitor’s browser and your server using TLS (Transport Layer Security). This encryption adds overhead — every new connection requires a TLS handshake where the browser and server negotiate encryption parameters and exchange keys. On a modern setup, this adds 1-2 round trips to the initial connection. On older configurations, it can add more. But this overhead is the foundation that enables HTTP/2, HTTP/3, and the trust signals that both browsers and search engines now require.
How the TLS Handshake Affects TTFB
When a visitor first connects to your site, the browser must complete a TCP handshake (one round trip) followed by a TLS handshake (one to two additional round trips) before any data transfers. Each round trip takes time proportional to the physical distance between the visitor and your server — roughly 20-50 milliseconds for same-continent connections, 100-200 milliseconds for cross-continent ones.
With TLS 1.2, the handshake typically requires two round trips. TLS 1.3 reduces this to one round trip, and supports 0-RTT resumption for returning visitors — meaning subsequent connections can begin transferring data immediately with zero additional handshake latency. This is a meaningful improvement: on a cross-continent connection, TLS 1.3 can save 100-200 milliseconds on the initial page load compared to TLS 1.2.
Most modern hosting environments and CDNs support TLS 1.3 by default. If your TTFB seems high, checking your TLS version is worth doing — an outdated server configuration stuck on TLS 1.2 is leaving performance on the table.
Why HTTPS Is a Net Positive for Performance
While TLS adds handshake overhead, HTTPS is required for HTTP/2 and HTTP/3 — protocols that dramatically improve performance through multiplexing (loading multiple resources over a single connection), header compression, and server push. A site on HTTP/1.1 without TLS loads resources sequentially and opens multiple connections; a site on HTTP/2 with TLS loads them in parallel over one connection. The net effect is that HTTPS sites with modern protocols are faster than HTTP sites, despite the encryption overhead.
HTTP/3, built on QUIC, goes further by eliminating the TCP handshake entirely and combining the transport and TLS handshakes into a single round trip. For sites served through a CDN that supports HTTP/3, the encryption overhead approaches zero for returning visitors.
Optimizing TLS Performance
OCSP Stapling eliminates a separate round trip the browser would otherwise make to verify your certificate’s validity. Most web servers support this but it may not be enabled by default.
Session resumption allows returning visitors to skip the full handshake by reusing previously negotiated parameters. TLS 1.3’s 0-RTT resumption is the most efficient form of this.
Certificate chain length matters — a certificate with unnecessary intermediate certificates adds bytes to the handshake. Keep the chain as short as possible while still being valid.
In practice, if you are on a reputable hosting provider or CDN with TLS 1.3 enabled, TLS performance is already well-optimized and not a significant bottleneck. The real performance gains from HTTPS come from the HTTP/2 and HTTP/3 protocols it enables.
Further Reading
- Why HTTPS Matters (web.dev) — The security, privacy, and performance reasons HTTPS is essential for modern sites.
- What Happens in a TLS Handshake (Cloudflare) — Clear visual explanation of TLS 1.2 vs 1.3 handshake flows and their latency impact.