SSL/TLS is essential for your website's security, but a careless configuration can add 200–500 ms of latency to every connection. The good news: with a few targeted optimizations — TLS 1.3, session reuse, OCSP Stapling, and correct headers — you can reclaim that time and in many cases load faster than before.
This guide covers the highest-impact SSL/TLS optimizations, ordered from simplest to most technical, with configuration examples for both Apache and Nginx.
Why SSL/TLS Can Slow Down Your Site
When a visitor opens your site for the first time, before a single byte of HTML is received, the TLS handshake must complete: the client and server negotiate the protocol, exchange certificates, and agree on session keys. In TLS 1.2 that process requires two round trips; in TLS 1.0 it can be even slower.
On top of that, the server may verify the certificate's validity in real time by contacting the Certificate Authority, adding another external request to the chain. If your server doesn't send the full certificate chain, the browser can't quickly trust your cert either.
Optimization 1: Upgrade to TLS 1.3
TLS 1.3 reduces the handshake from two round trips to one (1-RTT) and in reconnections can reach zero round trips (0-RTT). The practical effect is that the initial negotiation is 30–50% faster.
In Apache (>= 2.4.36 with OpenSSL >= 1.1.1):
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1In Nginx (>= 1.13.0 with OpenSSL >= 1.1.1):
ssl_protocols TLSv1.2 TLSv1.3;Restart the service and verify in SSL Labs that TLS 1.3 shows as "Yes".
Optimization 2: Enable OCSP Stapling
Normally the browser asks the CA whether your certificate is still valid — that request can take 100–300 ms if the CA's server is far away. With OCSP Stapling your server queries the CA in advance, caches the signed response, and includes it in the TLS handshake itself, eliminating that extra request.
In Apache:
SSLUseStapling On
SSLStaplingCache "shmcb:/var/run/ssl_stapling_cache(128000)"In Nginx:
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /path/to/full-chain.pem;
resolver 8.8.8.8 1.1.1.1 valid=60s;
resolver_timeout 5s;Verify with openssl s_client -connect yourdomain.com:443 -status; look for "OCSP Response Status: successful".
Optimization 3: TLS Session Reuse
Without session reuse, every new HTTP connection performs a full handshake. With session resumption enabled, the client and server remember the parameters from a previous session and resume without renegotiating. This is especially valuable on pages with many assets (images, scripts, fonts).
In Apache, reuse is active by default if SSLSessionCache is configured:
SSLSessionCache "shmcb:/var/run/ssl_scache(512000)"
SSLSessionCacheTimeout 300In Nginx:
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;Note: ssl_session_tickets off is a security recommendation — session tickets can weaken forward secrecy if the ticket key isn't rotated frequently.
Optimization 4: Complete and Ordered Certificate Chain
If your server sends only the domain certificate and omits the intermediates, the browser has to download them on its own — sometimes via AIA Fetching — adding extra network round trips. Make sure the certificate file you serve includes, in order:
- Your domain certificate.
- The CA's intermediate certificate(s) in chain order.
- Not the root certificate (browsers already have it).
In Apache:
SSLCertificateFile /path/to/domain.crt
SSLCertificateKeyFile /path/to/domain.key
SSLCertificateChainFile /path/to/intermediates.crtIn Nginx, combine domain and intermediates into one file:
cat domain.crt intermediates.crt > fullchain.crtOptimization 5: HSTS and Redirect Reduction
Every HTTP → HTTPS redirect adds one network round trip. With HSTS (HTTP Strict Transport Security) the browser knows in advance that your domain always uses HTTPS and goes there directly — skipping the redirect on repeat visits.
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"In Nginx:
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;Combine this with a single 301 redirect — not a chain — from HTTP to HTTPS so the first visit is as direct as possible.
| Technique | Estimated saving | Difficulty |
|---|---|---|
| TLS 1.3 | 100–200 ms per handshake | Low (1 config line) |
| OCSP Stapling | 100–300 ms per validation | Medium |
| Session reuse | Eliminates handshake on reconnects | Low |
| Complete chain | 50–150 ms on first connection | Low |
| HSTS | Full redirect round trip (~50–100 ms) | Low |
For deeper dives into certificates and protocols, the security SSL section has step-by-step guides covering each layer of the process.
Key Takeaways
- TLS 1.3 is the highest-impact upgrade: it cuts the handshake to one round trip and to zero for reconnections.
- OCSP Stapling removes the external CA request during the handshake, saving up to 300 ms.
- Session reuse avoids repeated negotiations and is especially noticeable on pages with many resources.
- An incomplete certificate chain forces the browser to make extra AIA requests — always include the intermediates.
- HSTS eliminates the HTTP → HTTPS redirect on repeat visits, removing an entire network round trip.
If you'd rather have an expert implement and verify all these optimizations for you, the team at elenlace.com can audit and configure your SSL/TLS so your site is both faster and more secure from day one.
FAQ
Will optimizing SSL negatively affect my site's security?
No — as long as you follow current recommendations. Enabling TLS 1.3, OCSP Stapling, and HSTS improves both security and performance. The one caveat is 0-RTT in TLS 1.3, which can be vulnerable to replay attacks on sensitive endpoints; avoid it on payment or login forms.
How much real-world speed improvement can I expect?
It depends on the user's baseline latency. For visitors more than 50 ms from your server, combining TLS 1.3 + OCSP Stapling + session reuse can reduce Time to First Byte (TTFB) by 200–600 ms on the first connection.
Do I need premium hosting to apply these optimizations?
Not necessarily. Most of these are plain text changes in Apache or Nginx that any hosting with SSH or server config access can apply. What you do need is for your host to be running OpenSSL 1.1.1 or higher for TLS 1.3 support.
Can HSTS cause problems if I later want to go back to HTTP?
In theory, yes: browsers that already received the HSTS header will keep forcing HTTPS for the duration set in max-age. That's why you should only enable HSTS when you're confident your certificate will renew without interruption. Start with a short max-age (300 seconds) to test before extending it to a full year.
Prefer it done for you? El Enlace handles hosting and professional web development.
Further reading
Other providers and guides worth comparing:
