Optimizing the TLS Handshake for Minimal Latency and Maximum Throughput

For years, the primary argument against ubiquitous encryption was CPU overhead. System administrators worried that terminating SSL/TLS would consume too many compute cycles, leading to the widespread practice of offloading encryption at the edge and passing unencrypted HTTP traffic to backend servers.

Today, that architectural assumption is entirely obsolete. Thanks to hardware acceleration like AES-NI integrated into modern processors, the CPU cost of encryption is virtually negligible. The modern TLS performance battle is no longer about compute—it is entirely about network latency, specifically Round Trip Time (RTT) and payload size.

As the industry prepares for maximum public certificate lifespans to drop to 90 days, and as Post-Quantum Cryptography (PQC) standards introduce larger cryptographic keys, optimizing the TLS handshake is critical. Failing to optimize your TLS configuration doesn't just result in a slower Time to First Byte (TTFB); it can lead to TCP fragmentation, dropped connections on mobile networks, and degraded Core Web Vitals.

Here is exactly how to strip unnecessary latency out of your TLS handshakes and prepare your infrastructure for the next generation of cryptographic standards.

The Math Behind the Payload: Switching to ECDSA

The most immediate performance gain you can achieve in your TLS configuration is abandoning RSA certificates in favor of Elliptic Curve Digital Signature Algorithm (ECDSA) certificates.

The performance bottleneck in a TLS handshake often comes down to the TCP Initial Congestion Window (initcwnd). When a server starts sending data over a new TCP connection, it doesn't send the entire payload at once. It sends a limited number of packets—typically 10 segments, or roughly 14KB of data—and waits for the client to acknowledge them before sending more.

If your TLS certificate chain and server configuration exceed this 14KB limit, the handshake requires an additional full round trip. On high-latency mobile networks, that extra round trip can add hundreds of milliseconds to your TTFB.

RSA keys are massive. A 3072-bit RSA key is currently the recommended minimum for secure communications, but it produces a large certificate footprint. By contrast, a 256-bit ECDSA key offers equivalent cryptographic strength but results in a significantly smaller certificate.

Switching to ECDSA shrinks the size of the certificate chain sent during the handshake, keeping the payload comfortably under the initcwnd limit. Furthermore, server CPU utilization for ECDSA signing operations is drastically lower than RSA, which prevents CPU spiking during traffic surges (the Thundering Herd problem).

You can generate an ECDSA private key and Certificate Signing Request (CSR) using OpenSSL with a single command:

# Generate a 256-bit prime256v1 (NIST P-256) ECDSA private key and CSR
openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 \
  -nodes -keyout server-ecdsa.key -out server-ecdsa.csr \
  -subj "/CN=yourdomain.com"

Major Certificate Authorities, including Let's Encrypt, now issue ECDSA certificates by default for ACME clients unless RSA is explicitly requested.

Trimming the Certificate Chain

When configuring your web server or ingress controller, you must provide the certificate chain so the client's browser can trace the certificate back to a trusted root. A common, latency-inducing mistake is including the Root Certificate in this chain.

The client's operating system or browser already has the Root Certificate stored in its local trust store. Sending it over the network during the handshake is a complete waste of bandwidth and pushes you closer to that dangerous TCP congestion limit.

You should only ever serve the leaf (server) certificate and the necessary intermediate certificates. If you are using Let's Encrypt, the fullchain.pem file is already optimized this way. If you are building the chain manually from a commercial CA, ensure the root is excluded.

Here is how a properly optimized Nginx configuration looks:

server {
    listen 443 ssl;
    server_name yourdomain.com;

    # Contains ONLY the leaf certificate and intermediate CA
    ssl_certificate /etc/ssl/certs/yourdomain_fullchain.pem; 
    ssl_certificate_key /etc/ssl/private/yourdomain_ecdsa.key;

    # Modern cipher suites prioritizing ECDSA
    ssl_ciphers 'TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-256-GCM-SHA384:TLS13-AES-128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305';
    ssl_prefer_server_ciphers on;
}

Eliminating Revocation Checks with OCSP Stapling

When a browser connects to your server, it needs to know if your certificate has been revoked. Historically, the browser would pause the handshake, perform a DNS lookup for the Certificate Authority's OCSP responder, establish a new TCP connection to the CA, and make an HTTP request to check the revocation status.

This process introduces massive latency and makes your site's performance dependent on the uptime of the CA's infrastructure.

OCSP Stapling solves this by shifting the burden to the server. Your web server queries the CA at regular intervals, caches the cryptographically signed response, and "staples" it directly to the initial TLS handshake. The client gets the certificate and the proof of its validity in a single payload.

To enable OCSP Stapling in Nginx, add the following directives to your server block:

    # Enable OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;

    # Point to the trusted certificate chain to verify the OCSP response
    ssl_trusted_certificate /etc/ssl/certs/yourdomain_fullchain.pem;

    # Use a reliable DNS resolver for the server to fetch the OCSP response
    resolver 1.1.1.1 8.8.8.8 valid=300s;
    resolver_timeout 5s;

TLS 1.3, 0-RTT, and HTTP/3

If you are still negotiating TLS 1.2, you are leaving performance on the table. TLS 1.3 was fundamentally redesigned to reduce the handshake from two round trips (2-RTT) to just one (1-RTT). It achieves this by combining the cryptographic parameters and the key exchange into the initial client hello.

TLS 1.3 also introduces 0-RTT (Early Data) for session resumption. If a client has previously connected to your server, they share a Pre-Shared Key (PSK). The client can use this PSK to encrypt the first HTTP request and send it alongside the very first TLS handshake packet. For returning visitors, the connection setup time is effectively zero.

However, 0-RTT comes with a severe security caveat: it is susceptible to replay attacks. Because the early data is sent before the server can guarantee the client's current state, an attacker on the network could intercept the 0-RTT packet and replay it multiple times.

To mitigate this, web servers must be configured to only accept idempotent requests (like HTTP GET) via 0-RTT. Data-altering requests (like POST or PUT) must wait for the full handshake.

In Nginx, you can enable 0-RTT and protect backend applications by passing the $ssl_early_data variable to your application, allowing it to reject non-idempotent early requests:

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_early_data on;

    location / {
        proxy_set_header Early-Data $ssl_early_data;
        proxy_pass http://backend;
    }

For the ultimate performance optimization, organizations are moving to HTTP/3 (QUIC). HTTP/3 discards TCP entirely in favor of UDP, integrating TLS 1.3 directly into the transport layer. This eliminates the TCP handshake completely, preventing head-of-line blocking and ensuring that packet loss on one stream doesn't stall the entire connection.

The Performance Impact of 90-Day Certificates

Google's proposal to reduce maximum public TLS certificate lifespans from 398 days to 90 days is driving a massive shift in how we manage infrastructure.

From a strict performance perspective, shorter lifespans are actually beneficial. Shorter-lived certificates mean smaller Certificate Revocation Lists (CRLs) and less reliance on OCSP, as the window of vulnerability for a compromised key is drastically reduced