Table of Contents
Last update on
The “S” in HTTPS stands for “secure” and that security is provided by SSL (aka TLS). It makes sense that you’d want to secure your site, right? After all, there are up to 90,000 attacks on WordPress sites every minute.
But for some reason, there’s a pervasive myth that SSL is slow. That installing an SSL certificate on your site will introduce too much overhead and slow things down. That might’ve been the case more than a decade ago, but this is 2018 and Google searches are now all done over HTTPS by default for 40,000 search queries per second.
In fact, when Google switched to HTTPS for everything by default, the search giant didn’t deploy additional machines or special hardware. Senior Staff Software Engineer Adam Langley who works on Google’s HTTPS serving infrastructure and Chrome’s network stack writes that SSL has limited impact on web performance:
On our production front-end machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead.
If Google can implement SSL, you can too. Plus, you kind of have to – from July when Chrome 68 is released, websites that are not using HTTPS will be labeled as “not secure” in the address bar.
In this post, we’ll take a look at how HTTPS affects website performance, as well as a few tips on how you can improve HTTPS performance for your site.
What’s the Difference Between SSL and TLS?
But first, you might be wondering what the difference is between SSL (Secure Socket Layer) and TLS (Transport Layer Security). Interestingly, there is no difference.
TLS was introduced as the successor to SSL 3.0 in 1999 and was designed to resolve insecurities in the SSL protocol.
So why do people still say SSL instead of TLS after all this time?
People in the security industry like SSL so much that they continued to use the acronym and still do to this day. Companies like Comodo didn’t change the name of SSL certificates to TLS certificates. Software that enables SSL on a server, such as OpenSSL, didn’t change their name to OpenTLS. The name SSL was ingrained and just stuck.
As for renaming the SSL protocol, it seems it was for political rather than technical reasons. Tim Dierks, the Director of Data Protection at Google writes that in the mid-90s during the Netscape and Microsoft browser wars, there was a lot of bargaining involved while developing the SSL protocol and – ultimately – leadership (and ownership) of the standard:
As a part of the horsetrading, we had to make some changes to SSL 3.0 (so it wouldn’t look the [Internet Engineering Task Force] IETF was just rubberstamping Netscape’s protocol), and we had to rename the protocol (for the same reason). And thus was born TLS 1.0 (which was really SSL 3.1). And of course, now, in retrospect, the whole thing looks silly.
And thus TLS was born. But everyone continued to say SSL anyway.
Note: For the rest of this post, I’ll use SSL and TSL interchangeably.
HTTP vs HTTPS?
HTTP stands for Hypertext Transfer Protocol. When you enter a URL in your address bar preceded by http:// it tells the browser to connect to the website via HTTP. In turn, HTTP uses the Transmission Control Protocol (TCP) to send and receive data packets over the web to load the site you want to access.
HTTPS stands for Hypertext Transfer Protocol Secure. When you enter a URL preceded by https:// it tells the browser to connect via HTTPS, which also uses TCP. But it does so within a connection encrypted by TLS.
Basically, it takes the HTTP protocol and simply layers a TLS encryption layer on top of it. Servers and clients still communicate exactly the same HTTP to each other, but over a secure TLS connection that encrypts and decrypts their requests and responses.
The SSL layer has two main purposes:
- It verifies that you are communicating directly to the serve that you think you are talking to, and
- It ensures that only the server can read what you send it and only you can read what it sends back.
What’s so clever about TLS/SSL is that anyone can intercept the messages you exchange with a server, including the ones where you agree on the key and encryption strategy to use, but they still can’t read any of the actual data that’s sent.
TLS Handshake
There is some latency added when you make the switch to HTTPS – the initial TLS handshake requires two extra round trips before the connection is established, compared to just one through an unencrypted HTTP port. But, as in the Google example I mentioned earlier, it’s minimal.
In 2010, Google introduced False Start, a technique that reduced the latency of a TLS handshake by 30%. But it abandoned the project a year later because it remained incompatible with a large number of websites that used SSL terminators, which offload SSL processing from servers.
However, False Start isn’t completely dead – it still works for sites on servers that support NPN extension.
Asymmetric Encryption
There is also an encryption process between the browser and server in which they exchange information using a process known as asymmetric encryption. It establishes a secure communications channel through which a session key is exchanged, allowing the browser and server to switch to a faster encryption process known as symmetric encryption.
Asymmetric encryption is slower than symmetric encryption due to the former’s longer key lengths and the complexity of the encryption algorithms used. However, tests between encrypted and unencrypted connections reveal a difference of only 5ms and a peak increase in CPU usage of just 2%. With dozens of parallel requests and hundreds of sequential requests, CPU usage during the tests never exceeded 5%.
Session Resumption
Session resumption greatly improves TLS performance by recalling information from a previously successful TLS session negotiation to bypass the most computationally intensive parts of the TLS session key negotiation.
TLS offers two session resumption mechanisms: session IDs (where the server and client each store their own secret state) and session tickets (where the client stores the server’s state, encrypted by the server).
In the case of session IDs, the server needs to keep track of previous sessions that could be continued at some point in time. This results in extra work for the server.
Session tickets were introduced to fix the problem of large server caches. With session tickets, the server uses a key to encrypt session information before storing it on the client. So the next time the client connects to the server, the server decrypts and reuses the session information. This means that the server can resume the sessions without keeping any information and all the additional load is done on the client.
Session resumption using session tickets is a beneficial technique for a lot of reasons – fewer round trips, fewer computations, and a lower congestion window, all without burdening your server.
Improving HTTPS Performance
Granted, SSL/TLS and HTTPS do introduce some slight delays that can impact the page load speed of your site. But the speed delays are so marginal that the security benefits outweigh any potential impacts on speed.
Still, there are some performance optimizations you can implement on your site after installing an SSL certificate so that it’s both secure and fast.
1. HTTP/2
HTTP/2 is a major revision of the HTTP protocol and attempts to solve many of the shortcomings and inflexibilities of HTTP/1.1. It’s benefits and features include:
- Multiplexing and concurrency: Several requests can be sent in rapid succession on the same TCP connection, and responses can be received out of order.
- Header compression: HTTP header size is drastically reduced.
- Stream dependencies: The client can indicate to the server which of the resources are more important
than the others. - Server push: The server can send resources the client has not yet requested, avoiding delays.
KeyCDN has a great free HTTP/2 testing tool if you want to check whether your server or CDN supports HTTP/2.
2. Brotli Compression
Brotli is an open source lossless compression algorithm developed by Google as an alternative to Gzip, Zopfli and Deflate that reduces bandwidth consumption and helps content load faster.
According to a Google case study, the format achieves 20–26% higher compression ratios over Zopfli with less CPU usage.
In order to use Brotli, both the client and the server must be Brotli compatible and running over an HTTPS connection to use it.
You can test if your server or CDN support Brotli using KeyCDN’s free testing tool.
3. HPACK Compression
Sites using HTTP/2 can make the most of HPACK compression. This technology uses Huffman encoding to achieve an average 30% reduction in header size.
There are three main benefits to using HPACK:
It’s resilient against compression-based attacks, such as CRIME (Compression Ratio Info-leak Made Easy,
Its ability to encode large headers using fixed Huffman encoding, and
It’s ability to encode commonly used headers as a variable length integer, as opposed to re-sending the whole header every time.
4. OCSP Stapling
OCSP stapling is a method for quickly determining whether or not an SSL certificate is valid. It allows a server to provide information on the validity of its own certificates rather than having to request the information from the certificate’s vendor. This ensures the safety and privacy of confidential data with and eliminates the need for the client to contact the certificate authority, reducing another request.
To enable OCSP stapling on your server, check out DigiCert’s detailed instructions.
5. Use a CDN
While you may not be able to make your packets physically travel faster, it is possible to make them travel a shorter distance. Using a CDN can significantly reduce the round trip times and the total costs of the TCP and TLS handshakes.
By allowing the user to terminate their connection with a nearby edge server, instead of crossing countries and oceans to your origin, the client gets the benefit of “early termination” with shorter round trips.
Leveraging early termination is equally useful for static and dynamic content: while static content can also be cached and served by the edge servers, dynamic requests can be routed over established connections from the edge servers to the origin.
Conclusion
Yes, it’s true that SSL can impact the performance of your website. But its efforts are so minor that saving a few milliseconds won’t outweigh the increased level of security that SSL affords.
With HTTP/2, HTTPS is only getting faster so any performance impact SSL adds to connections is dropping fast.
I’ll leave you with this: HTTP vs HTTPS test. This site offers a visual comparison of the load times for the unsecure HTTP and encrypted HTTPS HTTP/s versions of the same page. The results speak for themselves.
