How HTTPS Affects Access Speed and User Experience

HTTPS plays a crucial role in protecting user privacy and preventing traffic hijacking, but it also introduces latency and additional CPU load on web servers.

1. Introduction

This article introduces the impact of HTTPS on user experience.

2. Impact of HTTPS on Access Speed

Before discussing optimization strategies, the article outlines two main sources of delay introduced by HTTPS: extra network round‑trip time (RTT) and cryptographic computation.

2.1 Increased Network Delay

Both HTTP and HTTPS require DNS resolution, but the article assumes DNS cache is hit and ignores DNS lookup time for the main domain.

When a user accesses a site via HTTP (e.g., http://www.baidu.com), only a TCP three‑way handshake is needed before the HTTP request can be sent, with no additional computational cost.

In contrast, an HTTPS first request may add up to seven RTTs due to steps such as TCP handshake, HTTP 302 redirect, a second TCP handshake, TLS handshake phases, CA DNS lookup, OCSP/CRL checks, and key exchange.

The article lists the detailed sequence of these steps, each typically consuming one RTT, and notes that only a tiny fraction (<0.01 %) of requests experience the full seven‑RTT penalty, depending on conditions like first‑time request, full TLS handshake, OCSP/CRL enabled, and cache misses.

2.2 Increased Computational Delay

Beyond network latency, HTTPS adds significant CPU overhead on both browsers and servers. Typical additional computation exceeds 30 ms on the client side (50 ms on mobile, 10 ms on PC) and about 5 ms on the server side.

Browser overhead includes RSA signature verification, RSA/ECC key exchange operations, symmetric encryption/decryption, and integrity checks.

Server overhead includes RSA private‑key decryption, ECC key generation, symmetric encryption/decryption, and integrity verification.

3. Conclusion

The series will continue with targeted optimization measures for HTTPS performance.