How to Cut Nginx HTTPS Latency by 30% with TLS Tweaks

Why Optimize Nginx HTTPS Latency

Nginx is commonly used as a load balancer, reverse proxy, and gateway, and a well‑tuned instance should handle 50K‑80K requests per second while keeping CPU load manageable. For instant‑search experiences, each request must return within 100‑200 ms, making latency the primary optimization target.

TLS Handshake and Latency

Reducing latency often means cutting the number of round‑trips between client and server. A typical HTTPS handshake can add multiple round‑trips, each costing ~28 ms in ideal conditions, which quickly accumulates to hundreds of milliseconds before any data is transferred.

Nginx TLS Settings

Enable HTTP/2

HTTP/2 multiplexes many requests over a single connection, dramatically reducing round‑trips compared to HTTP/1.1. Enabling it in Nginx requires adding the http2 flag: listen 443 ssl;<br/>listen 443 ssl http2; Clients that do not support HTTP/2 automatically fall back to HTTP/1.1.

Verify HTTP/2 Is Enabled

In Chrome DevTools, check the Protocol column for h2. Alternatively, use curl --http2 -I https://yourdomain.com and look for HTTP/2 in the response.

Adjust Cipher Priority

Prefer modern, fast ciphers to reduce handshake time:

# Enable preferred ciphers<br/>ssl_prefer_server_ciphers on;<br/>ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';

Enable OCSP Stapling

OCSP stapling avoids a separate network request to the certificate authority during TLS verification, which can add seconds of delay, especially on iOS devices using Let's Encrypt certificates.

Two ways to address the issue:

Replace Let’s Encrypt with a locally trusted DV certificate.

Enable OCSP stapling.

ssl_stapling on;<br/>ssl_stapling_verify on;<br/>ssl_trusted_certificate /path/to/full_chain.pem;

Check OCSP Stapling Status

openssl s_client -connect test.kalasearch.cn:443 -servername kalasearch.cn -status -tlsextdebug < /dev/null 2>&1 | grep -i "OCSP response"

If the output shows a successful OCSP response, stapling is active.

Tune ssl_buffer_size

The buffer size controls how much data is sent per TLS record. Smaller values reduce latency for small responses (e.g., REST APIs) but increase overhead. A typical recommendation for APIs or websites is 4 KB, adjustable between 2‑16 KB:

ssl_buffer_size 4k;

Enable SSL Session Cache

Caching TLS sessions eliminates the full handshake on repeat connections. A 1 MB cache can store ~4,000 sessions; using 50 MB and a 4‑hour timeout is a common balance:

# Enable SSL cache to speed up repeat visits<br/>ssl_session_cache   shared:SSL:50m;<br/>ssl_session_timeout 4h;

Kalasearch Case Study: 30% Latency Reduction

Kalasearch, a domestic Algolia‑like instant‑search service, aims for sub‑100 ms engine processing and sub‑200 ms end‑to‑end response times. Monitoring revealed that TLS processing in Nginx consumed >300 ms on some devices, especially iOS, due to Let’s Encrypt verification delays.

After applying the TLS tweaks above, average SSL handshake time dropped from ~140 ms to ~110 ms nationwide, and the first‑visit slowdown on Apple devices disappeared. Overall search latency across the country fell to around 150 ms.

Conclusion

Optimizing Nginx TLS settings—enabling HTTP/2, selecting fast ciphers, activating OCSP stapling, tuning buffer sizes, and using an SSL session cache—can dramatically reduce HTTPS request latency. Future articles will explore deeper HTTP/2 benefits and trade‑offs for REST APIs.