Analyzing HTTPS Performance Overhead

https performance overhead

In today’s post we want to analyze HTTPS performance overhead and hopefully clear up some doubts that you may have had in the past. With best practices in place like early termination, cache-control and HTTP/2, factors such as the latency of the TLS handshake and additional roundtrips start becoming things of the past. Newer protocols, better hardware, and faster connections have started making up for these delays.

Costs & Overhead When Switching to HTTPS

There is always going to be some https performance overhead and possibly costs when switching to HTTPS, but the question is with today’s hardware, connectivity, and new HTTP/2 protocol, is the overhead and or cost even a factor worth considering anymore?

Price

let's encrypt

Price was always factor when it came to users debating whether they should migrate to HTTPS. But the costs associated with purchasing SSL certificates is changing. Our recent integration with Let’s Encrypt now lets KeyCDN customers deploy HTTPS with a custom zonealias for free! And web hosts are also following suit. Over the course of the next year you can expect a lot of the bigger names to now let you deploy an SSL certificate for free, with one click of a button.

For a lot of users, this takes the price factor totally out of the equation. There will still be some exceptions however as currently Let’s Encrypt only issues DV certificates. Enterprise customers will most likely still be purchasing organization and extended validation certificates. With this change in the future? Only time will tell.

TLS Overhead – SSL Performance Impact

There is some latency added when you switch to HTTPS. This is because the initial TLS handshake requires two extra roundtrips before the connection is established, compared to one through an unencrypted HTTP port. See diagram below.

CPU Load

There is also an encryption process between the browser and the server in which they exchange information using a process known as asymmetric encryption. However tests between encrypted and unencrypted connections show a difference of only 5ms, and a peak increase in CPU usage of only 2%. In January 2010, Gmail switched to using HTTPS for everything by default. They didn’t deploy any additional machines or special hardware and on their frontend machines, SSL/TLS accounted for less than 1% of the CPU load.

Many people believe that SSL/TLS takes a lot of CPU time and we hope the preceding numbers  will help to dispel that. – Adam Langley, Google “Overclocking SSL”

Operational Costs

If you are running on HTTP/2 (HTTPS) this only requires a single connection per origin which means few sockets, memory buffers as well as TLS handshakes. Because of this it you might be able to handle more users with fewer resources as opposed to HTTP.

HTTP vs HTTPs

We decided to run some test of HTTP vs HTTPS with our case study site and see what the results were. This is running on a small Vultr VPS with Nginx, PHP7, and HTTP/2 (over HTTPS). Our images are converted to WebP format using Optimus Image Optimizer and served up using WordPress Cache Enabler. And the content is accelerated by KeyCDN.

HTTP

WebPageTest

We ran 5 tests on WebPageTest to get a median result.

webpagetest http

Load Time First Byte Start Render DOC Complete Fully Loaded
Median Test First View 1.128s 0.136s 1.092s 1.128s 1.192s
Median Test Repeat View 0.797s 0.109s 0.790s 0.797s 0.869s

HTTPS

We then added an SSL certificate to our web host and deployed the certificate with KeyCDN via the new Let’s Encrypt integration. We did a quick force of HTTPS in our Nginx config (302 to new URLs) and rewrote all the old hard-coded WordPress URLs in the database.

WebPageTest

We ran 5 tests on WebPageTest to get a median result.

webpagetest https

Load Time First Byte Start Render DOC Complete Fully Loaded
Median Test First View 1.032s 0.207s 0.986s 1.032s 1.190s
Median Test Repeat View 0.835s 0.183s 0.748s 0.835s 0.929s

It is important to note that we didn’t use Pingdom in any of our tests because they use Chrome 39, which doesn’t support the new HTTP/2 protocol. HTTP/2 in Chrome isn’t supported until Chrome 43. You can tell this by looking at the User-Agent in the request headers of your test results.

pingdom user-agent

Pingdom user-agent

Note: WebPageTest uses Chrome 47 which does support HTTP/2.

webpagetest user-agent

WebPageTest user-agent

Comparing HTTP vs HTTPS Performance Tests

In our tests the HTTPS version actually was first to complete DOC load.

 

 

And when it came time to fully loaded it came down to right about the same.

 

 

Below are the timing comparisons between the two. As you can see they are both neck and neck.

Here are the final comparison results. The HTTPS version actually had a quicker first load time but as you can see they are very similar. Bottom Line: Making a lot of short requests over HTTPS will probably be slower than HTTP, but if you transfer a lot of data in a single request, the difference will be insignificant.

Load Time First Byte Start Render DOC Complete Fully Loaded
HTTP First View 1.128s 0.136s 1.092s 1.128s 1.192s
HTTPS First View 1.032s 0.207s 0.986s 1.032s 1.190s
HTTP Repeat View 0.797s 0.109s 0.790s 0.797s 0.869s
HTTPS Repeat View 0.835s 0.183s 0.748s 0.835s 0.929s

Go, the programming language, also has a great example of when you are dealing with a lot more images on a page and how HTTP/2 far exceeds that of HTTP/1.

Improving HTTPS Performance

There are quite a few things you can do to cancel out those slight delays and improve your HTTPS performance, such as implementing caching and utilizing HTTP/2. A lot of these are applicable even with SPDY.

1. HTTP Strict Transport Security

HTTP Strict Transport Security (HSTS) is a security enhancement that restricts web browsers to access web servers solely over HTTPS. It helps your performance by eliminating unnecessary HTTP-to-HTTPS redirects and shifting this responsibility to the client, which will automatically rewrite all links to HTTPS. All major up-to-date browsers currently support the use of HSTS with the exception of Opera Mini and versions previous of IE 11.

See our full guide on how to enable HTTP Strict Transport Security on your server.

2. Cache-Control

Cache-Control is an HTTP cache header comprised of a set of directives that allow you define when / how a response should be cached and for how long. HTTP caching occurs when a browser stores copies of resources for faster access. This can be used with your HTTPS implementation.

See our full guide on how to use the cache-control header directives.

3. Early Termination

Early termination is very important in decreasing the latency due to the TLS handshake. By serving your content from a Content Delivery Network (CDN) you are reducing the latency cost of each roundtrip between the client and the server, because the physical distance is less. A CDN allows you to terminate the connection closer to the user.

early termination

4. OCSP Stapling

OCSP stapling is an alternative approach to the original Online Certificate Status Protocol (OCSP) for determining whether an SSL certificate is valid or not. It does this by allowing the web server to query the OCSP responder and then caches the response. This allows the web server to check the validity of it’s certificates and eliminates the need for the client to contact the certificate authority, reducing another request.

OCSP stapling is automatically enabled when you server content with KeyCDN over HTTPS. See our guide on how to enable OCSP stapling on your server.

5. HTTP/2

And of course we have HTTP/2, which is the second major version update to the HTTP protocol since HTTP1.1. Benefits and features of HTTP/2 include:

  • Binary: As opposed to HTTP/1.1, which is textual.
  • Multiplexing: Allowing multiple requests and responses to be sent at the same time.
  • Header compression: Headers are compressed using a new algorithm which in turn reduces the amount of data.
  • One Connection: Allows a client to use just one connection per origin.
  • Server Push: Avoid delays by pushing responses it thinks the client will need to cache.
  • RTT: Reduces additional round trip times making your website load faster without any optimization.
  • ALPN extension: Allows faster-encrypted connections since the application protocol is determined during the initial connection.
  • Addresses the head of line blocking problem in HTTP/1.1.

Are you running over HTTP/2 yet? Use our free HTTP/2 test tool to check your web host and CDN provider.

6. HPACK Compression

Along with HTTP/2 comes the ability to use HPACK compression if your server supports it. This can result in headers that are decreased in size by over 30% on average. KeyCDN has enabled HPACK compression on all of it’s edge servers.

7. Brotli

Another performance advantage of using HTTPs is the ability to also use Brotli compression. Brotli is a new open source compression algorithim developed by Google as an alternative to Gzip, Zopfli, and Deflate. Google’s case study on Brotli has shown compression ratios of up to 26% smaller than current methods, with less CPU usage.

Both the server and the client (browser) must be Brotli compatible to take advantage of smaller file sizes and be running over an HTTPS connection. Brotli compression is currently supported by the following browsers:

  • Google Chrome: Chrome 49+
  • Mozilla Firefox: Firefox 44+ (released January 26, 2016)
  • Opera: Opera 36+

You can test your server to see if it supports Brotli our free Brotli test tool.

Summary

We didn’t see much of a delay from HTTPS and in fact some of the tests were faster! So the SSL performance impact is not as important as it used to be. The web is definitely moving in a new direction and TLS handshakes and certificates are no longer slowing us down. The are lots of ways as we mentioned above to even further improve upon your HTTPS performance and reduce your overhead. Of course we always recommend testing yourself as different setups and environments can vary.

HTTPS is here and it’s here to stay. Scott Helme saw a 42% growth in HTTPS usage by the top 1 million sites in the last 6 months.

What has been your experience? We would love to hear about it.

Related Articles

Analyzing HTTPS Performance Overhead was last modified: January 10th, 2017 by Brian Jackson
  • thbt

    If I’m understanding this correctly, I think most of the speed tests on this page are actually comparing HTTP to HTTP/2. That’s not the same thing as comparing HTTP to HTTPS (HTTP will always give you faster results than HTTPS if they’re both the same protocol version). It’s also worth pointing out that HTTP/2 doesn’t need a secure connection, it’s even faster with in non-secured connection. But unfortunately some browsers don’t currently support that for reasons having to do with politics rather than technological limitations.

    • Thanks for your comment!

      Yes, for a lot of our tests we are just assuming that if you are running HTTP/2 it is over a secure connection. A lot of what we are reiterating could also be said of SPDY. Go has a great comparison. https://http2.golang.org/gophertiles But again, the HTTP vs HTTPS and HTTP vs HTTP/2 terms do get thrown around alot (mixed and matched).

      And yes you are correct that HTTP/2 will work over non-secure connection, but like you said, because of browser support it will probably not go much further. But time will tell.

  • Hi Brian – This is very encouraging! Question: How is this possible given the extra roundtrips that TLS requires?

    What’s a good way to see the TLS RTTs? In the WebPageTest output (and in Chrome Dev Tools) all I see are the resource/file requests.

    One possibility occurs to me. Maybe the HTTP case is actually making lots of HTTPS connections for resources? For example, all the CDN requests, Bootstrap CDN, Google Fonts, MaxCDN, etc. In your HTTP test, are all those CDN requests HTTP or are there some HTTPS connections sprinkled in there? If there are some HTTPS in there, then maybe that’s why there isn’t much difference between the two test cases.

    Is the nginx install a vanilla make, or did you put in some compiler optimizations?

    You guys are great – keep up the good posts!

    • Hey Joe,

      The speed benefits of HTTP/2 must also be considered when comparing HTTPS vs HTTP since browsers currently only use HTTP/2 for HTTPS websites. It allows you to use just one connection, uses multiplexing, HPACK compression etc. All of these benefits help further optimize the delivery of your websites assets to the user.

      You can see the SSL negotiation time by looking at the pink bar in your webpagetest results. In the HTTP test above all of the assets were delivered over HTTP and for the HTTPS test all of the assets were delivered over HTTPS.

      Lastly, the tests were run on a small Vultr VPS with Nginx, PHP7, and HTTP/2 (for HTTPS tests).

  • Thomas

    This is not our experience. We are on shared hosting, and the Webpagetest results indicate that when using HTTPS, the time to first byte almost doubles, and the load time increases by 50% compared to the same page accessed via HTTP.

    • Are you using HTTP/2?

Share This