SSL/TLS Performance Tuning: Encryption Without the Latency Cost

Q: How does OCSP stapling improve performance?

Without OCSP stapling, the client contacts the CA's OCSP responder, adding 50-300ms. OCSP stapling includes revocation status directly in the handshake, eliminating this round trip.

Q: What is the CPU cost of TLS encryption?

On servers with AES-NI hardware acceleration, AES-128-GCM processes data at 5-10 GB/s per core. The CPU overhead is under 1% for typical web workloads.

By Carlos Reyes · June 14, 2026 · 11 min read

TLS encryption is non-negotiable for modern web applications. Beyond security, it's a ranking factor for search engines, a requirement for HTTP/2 and HTTP/3, and necessary for browser features like service workers. The question is not whether to use TLS, but how to configure it so the security benefit comes without a meaningful performance penalty.

A poorly configured TLS setup can add 300ms or more to the initial connection. A well-optimized configuration adds under 50ms. The difference comes down to protocol version, cipher selection, certificate chain length, session management, and certificate status checking. Each of these factors is tunable.

TLS Handshake Performance

The TLS handshake establishes encryption parameters between client and server before any application data can be exchanged. This handshake is the primary source of TLS-related latency and occurs on every new connection.

TLS 1.3 Performance Gains

TLS 1.3 reduces the full handshake from 2 round trips (TLS 1.2) to 1 round trip by combining key exchange and authentication into a single message flight. On a connection with 50ms RTT, this saves 50ms on every new connection. For users with higher-latency connections (mobile networks, distant servers), the savings can exceed 150ms.

TLS 1.3 also supports 0-RTT resumption, where a client that has previously connected can send application data with the very first handshake message. This eliminates the handshake latency entirely for returning visitors, making resumed TLS 1.3 connections as fast as unencrypted connections.

Enable TLS 1.3 on your servers. It provides a free 50-150ms latency reduction per new connection compared to TLS 1.2, with stronger security and simpler cipher configuration.

Session Resumption

Full TLS handshakes involve expensive asymmetric cryptography (RSA or ECDHE key exchange). Session resumption mechanisms allow clients to skip this expensive step on subsequent connections, reusing previously negotiated encryption parameters.

Session Tickets

The server encrypts the session state into a ticket and sends it to the client. On reconnection, the client presents the ticket, and the server decrypts it to restore the session. No server-side storage is required, making session tickets work across multiple servers behind a load balancer — as long as all servers share the same ticket encryption key.

# nginx TLS session ticket configuration ssl_session_tickets on; ssl_session_timeout 24h; # Rotate ticket keys periodically (every 12 hours recommended) # Use the same key across all servers behind the load balancer ssl_session_ticket_key /etc/nginx/ssl/ticket.key; # TLS 1.3 configuration ssl_protocols TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers off; # Let client choose in TLS 1.3 # ECDSA certificate (faster than RSA) ssl_certificate /etc/nginx/ssl/cert-ecdsa.pem; ssl_certificate_key /etc/nginx/ssl/key-ecdsa.pem; # OCSP stapling ssl_stapling on; ssl_stapling_verify on; resolver 1.1.1.1 8.8.8.8 valid=300s; resolver_timeout 5s;

0-RTT Early Data

TLS 1.3 0-RTT allows the client to send application data in the very first handshake message, achieving zero-latency connection establishment for returning visitors. The server can begin processing the request before the handshake completes.

The security tradeoff is that 0-RTT data is vulnerable to replay attacks: an attacker who captures the initial message can replay it, causing the server to process the request twice. For this reason, 0-RTT should only be enabled for idempotent requests (GET requests that don't modify state). POST requests and API mutations should not use 0-RTT.

Certificate Chain Optimization

During the TLS handshake, the server sends its certificate chain to the client for validation. A longer chain means more bytes transmitted during the handshake and more signature verification on the client side.

Chain Length

An optimal certificate chain contains exactly the server certificate and intermediate certificates — typically 2-3 certificates totaling 3-5 KB. Including unnecessary certificates (the root CA, expired intermediates) wastes bandwidth and processing time. Omitting required intermediates causes validation failures on some clients.

ECDSA vs RSA Certificates

Aspect	RSA 2048-bit	ECDSA P-256	Performance Impact
Certificate size	~1,200 bytes	~400 bytes	ECDSA saves ~2.4KB over full chain
Handshake sign	~2ms	~0.5ms	ECDSA 4x faster on server
Handshake verify	~0.1ms	~0.3ms	RSA slightly faster for client
Key exchange	N/A (use ECDHE)	Built-in	ECDSA simplifies handshake
Compatibility	Universal	Modern clients only	Dual-cert config for legacy

ECDSA certificates are smaller and faster to sign, reducing both the bytes transmitted during the handshake and the server CPU cost. For modern deployments, ECDSA P-256 certificates are recommended. Servers that must support legacy clients can configure dual certificates (ECDSA primary, RSA fallback).

OCSP Stapling

Online Certificate Status Protocol (OCSP) allows clients to check whether a server's certificate has been revoked. Without stapling, the client makes a separate HTTP request to the certificate authority's OCSP responder during the TLS handshake. This adds 50-300ms of latency depending on the OCSP responder's location and load.

With OCSP stapling, the server fetches the OCSP response periodically (typically every few hours), caches it, and includes it in the TLS handshake. The client receives the revocation status directly from the server without making an additional network request. This eliminates 50-300ms of handshake latency and removes a privacy concern (the OCSP responder no longer sees which sites users visit).

Cipher Suite Selection

Cipher suites determine the encryption algorithms used for the TLS connection. Different ciphers have different computational costs, affecting both handshake latency and ongoing encryption overhead.

# Recommended cipher configuration (nginx) # TLS 1.3 ciphers (configured automatically, cannot be changed): # TLS_AES_256_GCM_SHA384 # TLS_CHACHA20_POLY1305_SHA256 # TLS_AES_128_GCM_SHA256 # TLS 1.2 ciphers (ordered by preference): ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305'; # Performance notes: # AES-128-GCM: fastest on hardware with AES-NI (most servers) # ChaCha20-Poly1305: fastest on mobile (no AES-NI) # AES-256-GCM: 10-15% slower than AES-128-GCM, rarely needed

Hardware Acceleration

Modern server CPUs include AES-NI instructions that accelerate AES encryption by 5-10x. With AES-NI, the encryption overhead of TLS is nearly zero: AES-128-GCM processes data at 5-10 GB/s on a single core. Mobile devices without AES-NI benefit from ChaCha20-Poly1305, a cipher designed for efficient software implementation.

HTTP/2 and HTTP/3 Multiplexing

TLS enables HTTP/2 and HTTP/3, which provide significant performance improvements that often more than offset the TLS handshake cost. HTTP/2 multiplexes multiple requests over a single TLS connection, eliminating the need for multiple parallel connections (and their individual TLS handshakes). HTTP/3 over QUIC integrates TLS 1.3 into the transport layer, combining the TLS and transport handshakes into a single round trip.

For sites that previously required 6-8 parallel HTTP/1.1 connections (each with its own TLS handshake), migrating to HTTP/2 over a single TLS connection reduces total handshake overhead by 80-90%.

TLS Performance Monitoring

Track these metrics to identify TLS performance issues:

Handshake time: Time from TCP connection to TLS connection established. Target under 100ms for full handshake, under 50ms for resumed.
Session resumption rate: Percentage of connections using session resumption. Target above 80% for sites with returning visitors.
Certificate chain size: Bytes transmitted for the certificate chain. Target under 5KB.
OCSP stapling hit rate: Percentage of handshakes that include a stapled OCSP response. Target 100%.
TLS version distribution: Percentage of connections using TLS 1.3 vs 1.2. Investigate why TLS 1.2 connections persist.
Cipher suite distribution: Which ciphers are negotiated. Ensure hardware-accelerated ciphers are preferred.

Frequently Asked Questions

How much latency does TLS add to connections?

A full TLS 1.3 handshake adds 1 round trip (RTT) — typically 20-100ms depending on network latency. TLS 1.2 adds 2 RTTs (40-200ms). Session resumption reduces this to 0-1 RTT, and TLS 1.3 0-RTT eliminates handshake latency entirely for returning visitors. Ongoing encryption overhead (AES-GCM with hardware acceleration) is under 1% of CPU.

Should I use ECDSA or RSA certificates?

Use ECDSA P-256 certificates for new deployments. They are smaller (saving ~2.4KB per handshake), faster to sign (4x faster), and provide equivalent security to RSA 3072-bit keys. If you need to support very old clients (Windows XP, Android 2.x), configure dual certificates with ECDSA primary and RSA fallback.

Is TLS 1.3 0-RTT safe to enable?

0-RTT is safe for idempotent requests (GET requests that don't change state). It is vulnerable to replay attacks, so do not enable it for POST requests, API mutations, or any operation that modifies data. Most web servers allow you to limit 0-RTT to safe request methods. The performance benefit (zero latency for returning visitors) is significant for content-heavy sites.

How does OCSP stapling improve performance?

Without OCSP stapling, the client must contact the certificate authority's OCSP responder to check certificate revocation status, adding 50-300ms to the handshake. OCSP stapling includes the revocation status directly in the TLS handshake, eliminating this additional round trip. It also removes the privacy concern of the CA seeing which sites users visit.

What is the CPU cost of TLS encryption?

On servers with AES-NI hardware acceleration (nearly all modern x86 CPUs), AES-128-GCM encryption processes data at 5-10 GB/s per core. The CPU overhead is under 1% for typical web workloads. The TLS handshake is more expensive (2-5ms for ECDHE key exchange), but session resumption reduces the frequency of full handshakes.