TLS adds a handshake before any data is exchanged, which does add latency — but the actual cost today is small, and often offset entirely by other factors that come bundled with HTTPS adoption.
Where the real cost is
- The handshake itself: TLS 1.2 requires two network round-trips before application data flows; TLS 1.3 cut this to one round-trip, roughly halving the handshake latency cost.
- Session resumption further reduces this for repeat visitors, since the browser can skip much of the handshake on reconnect.
- CPU overhead for encryption itself is now negligible on modern hardware — this was a real cost in the early 2000s, not today.
Why HTTPS sites often feel faster overall
HTTPS unlocks HTTP/2 (and HTTP/3) support in every major browser, both of which bring real performance improvements — multiplexed connections, header compression — that generally outweigh the handshake cost. Net effect for most real sites: migrating to HTTPS is speed-neutral to speed-positive, not a meaningful slowdown.
Why the TLS 1.3 handshake specifically halved this cost
TLS 1.2 requires two full network round trips before any application data can flow; TLS 1.3 collapsed this to a single round trip by having the client send its likely key exchange parameters upfront — a change that matters disproportionately for visitors on higher-latency mobile connections, where each round trip costs meaningfully more than on fast broadband.
What session resumption adds on top of the protocol-level improvements
For a repeat visitor within a session's lifetime, the browser and server can skip much of the full handshake by reusing previously negotiated parameters — meaning the real-world, cumulative cost of TLS across an entire visit is considerably lower than a naive per-request calculation would suggest.
A rough way to measure the actual cost on your own site
Browser DevTools' Network tab breaks down connection timing into distinct phases, including the TLS handshake specifically, letting you see the actual, exact cost on your own infrastructure rather than relying on general industry figures that may not reflect your specific server, location, or configuration.
Why CPU-bound encryption cost is now considered essentially negligible
Modern CPUs include dedicated hardware instructions, AES-NI on most current processors, specifically accelerating the encryption operations TLS relies on, meaning the computational cost of encryption itself, a genuine bottleneck in the early 2000s, is now a rounding error on virtually any current server hardware.
What actually still costs meaningful time in a modern HTTPS connection
For a well-configured modern server, the remaining measurable cost is almost entirely the handshake's network round trips rather than any computational overhead — which is exactly why TLS 1.3's reduction from two round trips to one, and session resumption for repeat visitors, matter more to real-world performance than raw encryption speed does today.
The short, current answer worth keeping in mind
On modern hardware and with TLS 1.3, the honest answer today is that HTTPS costs a small, generally imperceptible amount of latency and gains real performance benefits through HTTP/2 and session resumption — close to a wash for most sites, not the meaningful slowdown it represented two decades ago.
What a realistic benchmark comparison looks like between HTTP and HTTPS today
Running a controlled benchmark comparing an HTTP and HTTPS version of the identical page on modern infrastructure typically shows a difference measured in single-digit milliseconds, often within normal network variance — a stark contrast to the multi-hundred-millisecond difference that would have been observed on early-2000s hardware.
A closing thought
A quick closing thought: on any reasonably current infrastructure, this question has a genuinely reassuring, settled answer today — worth remembering the next time outdated performance concerns come up in a decision about migrating to HTTPS.