HTTP vs HTTPS performance

Question

Are there any major differences in performance between http and https? I seem to recall reading that HTTPS can be a fifth as fast as HTTP. Is this valid with the current generation webservers/browsers? If so, are there any whitepapers to support it?

Ruination

You should also check out HTTP2, which browsers currently only support when used with HTTPS. en.wikipedia.org/wiki/HTTP/2 – Zippora

https is always slower than http (or much slower). – Fritzfritze

If there is some transparent caching happening (squid for example) then then it might be significant. The protocol itself, I don't think it has a big overhead. – Fright

Answer 1

There's a very simple answer to this: Profile the performance of your web server to see what the performance penalty is for your particular situation. There are several tools out there to compare the performance of an HTTP vs HTTPS server (JMeter and Visual Studio come to mind) and they are quite easy to use.

No one can give you a meaningful answer without some information about the nature of your web site, hardware, software, and network configuration.

As others have said, there will be some level of overhead due to encryption, but it is highly dependent on:

• Hardware
• Server software
• Ratio of dynamic vs static content
• Client distance to server
• Typical session length
• Etc (my personal favorite)
• Caching behavior of clients

In my experience, servers that are heavy on dynamic content tend to be impacted less by HTTPS because the time spent encrypting (SSL-overhead) is insignificant compared to content generation time.

Servers that are heavy on serving a fairly small set of static pages that can easily be cached in memory suffer from a much higher overhead (in one case, throughput was havled on an "intranet").

Edit: One point that has been brought up by several others is that SSL handshaking is the major cost of HTTPS. That is correct, which is why "typical session length" and "caching behavior of clients" are important.

Many, very short sessions means that handshaking time will overwhelm any other performance factors. Longer sessions will mean the handshaking cost will be incurred at the start of the session, but subsequent requests will have relatively low overhead.

Client caching can be done at several steps, anywhere from a large-scale proxy server down to the individual browser cache. Generally HTTPS content will not be cached in a shared cache (though a few proxy servers can exploit a man-in-the-middle type behavior to achieve this). Many browsers cache HTTPS content for the current session and often times across sessions. The impact the not-caching or less caching means clients will retrieve the same content more frequently. This results in more requests and bandwidth to service the same number of users.

Relevance

James, was hoping you might be able to provide a brief commentary on the comparative speed of this aSSL solution: assl.sullof.com/assl Off the top of your head, is there anything gained performance-wise? Thanks! – Decastere

PS: It's my understanding that this solution requires a client side key (which could be implemented in the case of a webkit/titanium app), the goal is simply to maximize this component of the speed equation along with the others you mentioned. – Decastere

Sorry if this has been covered, but there are h/w solutions available for severely impacted servers, see en.wikipedia.org/wiki/SSL_acceleration and I note Microsoft has been working with IHVs on "SSL Chimney" which allows the NIC to 'do the math'. Apparently the SSL overhead affects busy Exchange Servers, too. – Semiautomatic

This post does not really answer the question. It seems that Jim Geurts is asking about the performance nature of HTTP and HTTPS themselves, not a particular implementation. HTTPS undeniably slower because it does more work. So the question is, how much slower? Everyone knows that if you add more variables, you get varying results. – Soldier

This answer mentions a lot of irrelevant (in other words wrong) stuff at the beginning. He takes 5 paragraphs to get to the right answer, which is HANDSHAKING. – Medovich

Content served over HTTPS will not be cached by proxies. All modern browsers cache HTTPS content by default, unless explicitly told not to as explained by Jeff Atwood – Patriciate

We have some backend services on a closed network that are actually less performant when hit via HTTP than they are when hit via HTTPS. We're talking like 3 seconds for HTTP vs. a very small fraction of a second for HTTPS. Any idea why that might be the case? – Toname

Answer 2

HTTPS requires an initial handshake which can be very slow. The actual amount of data transferred as part of the handshake isn't huge (under 5 kB typically), but for very small requests, this can be quite a bit of overhead. However, once the handshake is done, a very fast form of symmetric encryption is used, so the overhead there is minimal. Bottom line: making lots of short requests over HTTPS will be quite a bit slower than HTTP, but if you transfer a lot of data in a single request, the difference will be insignificant.

However, keepalive is the default behaviour in HTTP/1.1, so you will do a single handshake and then lots of requests over the same connection. This makes a significant difference for HTTPS. You should probably profile your site (as others have suggested) to make sure, but I suspect that the performance difference will not be noticeable.

Coniah

It turns out this handshaking cost will be paid about 4-10x per session, at minimum, due to most browsers using multiple connections to the same server. Depending on how long the https-keep-alive is for a browser, it may be incurred repeatedly during a session. – Relevance

regarding HTTP keepalive feature, we have experienced the scenario where the connections are not staying persistent. For each request the request connection is being built and teared down-meaning MA-SSL handshake. There are possibilities wherein the client or server may have configured to closing the connections. Typically occurs in Tomcat/Websphere environments. – Nasopharynx

@JamesSchek Multiple connections should reuse the same SSL session, which changes the picture quite a bit. Same applies even if HTTP keep-alive isn't working. – Silures

@EJP That's true. And in 2013, most browsers/servers and SSL/TLS implementations make use of session reuse. In 2008, it wasn't a always a safe assumption. – Relevance

This question shows up high in Google for "http vs https performance." While the answer above was true in 2008, it's no longer true in 2015 and shouldn't be used as the basis for decisions to avoid using https. – Nairobi

Can anyone please update this for 2019? I've been looking at the answers and none of them mentions how HTTPS is the de-facto standard and recommended security practice these days. – Catchpenny

Answer 3

To really understand how HTTPS will increase your latency, you have to understand how HTTPS connections are established. Here is a nice diagram. The key is that instead of the client getting the data after 2 "legs" (one round trip, you send a request, the server sends a response), the client won't get data until at least 4 legs (2 round trips). So, if it takes 100 ms for a packet to move between the client and the server, your first HTTPS request will take at least 500 ms.

Of course, this can be mitigated by re-using the HTTPS connection (which browsers should do), but it does explain part of that initial stall when loading up an HTTPS web site.

Victuals

In terms of A Java client, how can one make HTTPS connection re-usable? I mean, can I make a static object of HttpsConnection and re-use it? (in a web application context) – Phio

5 years later, the link to the nice +1 diagram doesn't work, can anyone find it and put it in the answer instead of a link? – Lepidus

@FRoZen found alternative link – Thickleaf

Also I think this page a a very good diagram of http to better understand the whole picture: blog.catchpoint.com/2010/09/17/anatomyhttp – Normannormand

@Nikhil Java automatically reuses the underlying connection and shares it across requests, unless forced by user via disconnect. Check the docs. – Nich

Answer 4

The overhead is NOT due to the encryption. On a modern CPU, the encryption required by SSL is trivial.

The overhead is due to the SSL handshakes, which are lengthy and drastically increase the number of round-trips required for a HTTPS session over a HTTP one.

Measure (using a tool such as Firebug) the page load times while the server is on the end of a simulated high-latency link. Tools exist to simulate a high latency link - for Linux there is "netem". Compare HTTP with HTTPS on the same setup.

The latency can be mitigated to some extent by:

• Ensuring that your server is using HTTP keepalives - this allows the client to reuse SSL sessions, which avoids the need for another handshake
• Reducing the number of requests to as few as possible - by combining resources where possible (e.g. .js include files, CSS) and encouraging client-side caching
• Reduce the number of page loads, e.g. by loading data not required into the page (perhaps in a hidden HTML element) and then showing it using client-script.

Stringfellow

I highly concur with @MarkR. My recent profile of my homepage, HTTP vs HTTPS, the average load times were 1.5s and 4.5s, respectively. When looking at the connection details, the big slow down factor was the extra round trips due to the SSL handshake. Mobile browsers over 3G was even worse. The numbers were 5s and 9s, respectively. – Huckaback

Answer 5

December 2014 Update

You can easily test the difference between HTTP and HTTPS performance in your own browser using the HTTP vs HTTPS Test website by AnthumChris: “This page measures its load time over unsecure HTTP and encrypted HTTPS connections. Both pages load 360 unique, non-cached images (2.04 MB total).”

The results may surprise you.

It's important to have an up to date knowledge about the HTTPS performance because the Let’s Encrypt Certificate Authority will start issuing free, automated, and open SSL certificates in Summer 2015, thanks to Mozilla, Akamai, Cisco, Electronic Frontier Foundation and IdenTrust.

June 2015 Update

Updates on Let’s Encrypt - Arriving September 2015:

• Let's Encrypt Launch Schedule (Jun 16, 2015)
• Let's Encrypt Root and Intermediate Certificates (Jun 4, 2015)
• Draft Let's Encrypt Subscriber Agreement (May 21, 2015)

More info on Twitter: @letsencrypt

For more info on HTTPS and SSL/TLS performance see:

• Is TLS Fast Yet?
• High Performance Browser Networking, Chapter 4: Transport Layer Security
• Overclocking SSL
• Anatomy and Performance of SSL Processing

For more info on the importance of using HTTPS see:

• Why HTTPS for Everything? (The HTTPS-Only Standard)
• Let’s Encrypt (Internet Security Research Group)
• HTTPS Everywhere (Electronic Frontier Foundation)

To sum it up, let me quote Ilya Grigorik: "TLS has exactly one performance problem: it is not used widely enough. Everything else can be optimized."

Thanks to Chris - author of the HTTP vs HTTPS Test benchmark - for his comments below.

Sector

And protocols like SPDY might give HTTPS(+SPDY) a performance advantage over HTTP due to a more efficient protocol. – Sunbeam

Good news. Let’s Encrypt isn’t operational yet. Stay tuned for more as they get closer to launching the CA in Q2 2015. – Mccarthyism

That "HTTP vs HTTPS Test" is intentionally deceiving, please don't link to it. What that page actually does is compare HTTP to SPDY. It's true, if you don't believe me, try it in IE and see what it says. There is no situation where a HTTP request is faster than an equivalent HTTPS request. – Orthogenetic

@Orthogenetic Of course, that's the whole point. You can't have SPDY without HTTPS. The point is that only when you have HTTPS connection then certain speed improvements can be used (like switching to SPDY or HTTP/2) that can't be used over plain HTTP (for various reasons). Result: you need to use HTTPS to get faster than HTTP. See caniuse.com/spdy for browsers that support SPDY. See caniuse.com/http2 for browsers that support HTTP/2. There's no reason to not use it where it's available. – Sector

Google forced SPDY to only use secured connections for political reasons, not technical ones. HTTP/2 (which uses SPDY's same speed improvement techniques) can use an unsecured connection, and it's slightly faster when it does. An unsecured connection is still always at least a bit faster than a secured connection using the same protocol. The "HTTP vs HTTPS Test" is intentionally deceptive and misleading. – Orthogenetic

The website provides a quantitative comparison with real numbers, and it's an effort to encourage more people to protect their users with HTTPS. Opinions only take us so far, and we always have the freedom to build slow, insecure applications for IE over HTTP. I will always vote for building fast, bleeding-edge, and secure web applications for Chrome/Firefox over with HTTPS. – Acker

I think the test is broken, it results in 89% faster for HTTPS :D lol. Does that depend by the social sharing buttons? – Dyun

@Chris, you may want to answer that last comment from DarioOO. Thanks. – Sector

@DariOO: No, I purposefully excluded third-party scripts (social sharing buttons) from loading until the test completes, and no IO blocking should occur – Acker

@Chris after documenting myself I think the performance gain is due to Firefox using HTTP 2.0, however the culprit is that I think that when the test start the SSL handshake is already completed and is not measured, still the HTTPS is noticeable faster (even if handshake is not measured?), maybe just a bit slower than numbers displayed – Dyun

The arithmetic on httpvshttps.com looks wrong: 1.7 seconds compared to 34 seconds is not "95% faster." It's 20× faster, or 1900% faster. It should compare speeds rather than duration. – Psycho

@Chris There's another comment here on the arithmetic in your benchmarks that you may want to take a look at because I cannot really answer it. – Sector

The test is misleading and deceiving. Per tools.ietf.org/html/rfc7540#section-3.2 there is no reason why HTTP/2 cannot be used on a non-secure connection. Big companies are pushing for universal HTTPS usage. The reasons vary. But the fact remains. Unless there is personal data on the page there is no reason to run SSL. And while yes with today's computers the SSL handshake is trivial. If we start to say this and that is trivial stuff will simply get bogged down. Produce a 1:1 test of HTTP/1.1 vs HTTP/1.1 SSL and HTTP/2 vs HTTP/2 SSL. Then Discuss. – Pyramidon

@AnthumChris Not everyone is building web apps with sensitive data. See if your proselytizing for HTTPS everywhere would survive footing the bill for a few petabytes and many billion requests of content delivery. – Cachalot

Answer 6

The current top answer is not fully correct.

As others have pointed out here, https requires handshaking and therefore does more TCP/IP roundtrips.

In a WAN environment typically then the latency becomes the limiting factor and not the increased CPU usage on the server.

Just keep in mind that the latency from Europe to the US can be around 200 ms (torundtrip time).

You can easily measure this (for the single user case) with HTTPWatch.

Jointress

Answer 7

In addition to everything mentioned so far, please keep in mind that some (all?) web browsers do not store cached content obtained over HTTPS on the local hard-drive for security reasons. This means that from the user's perspective pages with plenty of static content will appear to load slower after the browser is restarted, and from your server's perspective the volume of requests for static content over HTTPS will be higher than would have been over HTTP.

Handcuff

Sending the header "Cach-Control: max-age=X, public", will cause modern browsers (just tested FF4, Chrome12, IE8, IE9) to cache the content. However, I noticed these browsers send a conditional GET, which could incur additional latency for the extra round trips, especially if an SSL connection isn't cached (Keep Alive). – Huckaback

Answer 8

There isn't a single answer for this.

Encryption will always consume more CPU. This can be offloaded to dedicated hardware in many cases, and the cost will vary by algorithm selected. 3des is more expensive than AES, for example. Some algorithms are more expensive for the encrypter than the decryptor. Some have the opposite cost.

More expensive than the bulk crypto is handshake cost. New connections will consume much more CPU. This can be reduced with session resumption, at the cost of keeping old session secrets around until they expire. This means that small requests from a client that doesn't come back for more are the most expensive.

For cross internet traffic you may not notice this cost in your data rate, because the bandwidth available is too low. But you will certainly notice it in CPU usage on a busy server.

Doubloon

Answer 9

I can tell you (as a dialup user) that the same page over SSL is several times slower than via regular HTTP...

Holily

Good point. I also found that load times via the mobile phone network (3G) is also 2x to 3x slower. – Huckaback

Yep! Just a year and a half after that answer I moved to a new house and was finally able to switch to DSL for less money than having a POTS line! – Holily

Answer 10

In a number of cases the performance impact of SSL handshakes will be mitigated by the fact that the SSL session can be cached on both ends (desktop and server). On Windows machines for example the SSL session can be cached for up to 10 hours. See http://support.microsoft.com/kb/247658/EN-US . Some SSL accelerators will also have parameters allowing you to tune the time the session is cached.

Another impact to consider is that static content served over HTTPS will not be cached by proxies, and this may reduce performance across multiple users accessing the site over the same proxy. This can be mitigated by the fact that static content will be cached at desktops as well, Internet Explorer versions 6 and 7 cache cacheable HTTPS static content unless instructed to do otherwise (Tools Menu/Internet Options/Advanced/Security/Do not save encrypted pages to disk).

Selfexecuting

Answer 11

I made a small experiment and got 16% time difference for the same image from flickr (233 kb):

http://farm8.staticflickr.com/7405/13368635263_d792fc1189_b.jpg

https://farm8.staticflickr.com/7405/13368635263_d792fc1189_b.jpg

Of course these numbers depends on many factors, such as computer performance, connection speed, server load, QoS on path (the particular network path taken from browser to the server) but it shows the general idea: HTTPS is slowser then HTTP, since it requesres more operations to complete (SSL handshaking and encoding/decoding data).

Valuation

can't create a statistical analysis metric based off 2 requests, one for each. – Luciana

Answer 12

Here's a great article (a little bit old, but still great) on SSL handshake latency. Helped me identifying SSL as the main cause of slowness for clients who were using my app through slow Internet connections:

http://www.semicomplete.com/blog/geekery/ssl-latency.html

Joellajoelle

Answer 13

Since I am investigating same problem for my project, I found these slides. Older but interesting:

http://www.cs.nyu.edu/artg/research/comparison/comparison_slides/sld001.htm

Stubbed

I found the simplified diagrams helpful but also a bit lacking. I think To better understand the number of round trips this page for http is helpful: blog.catchpoint.com/2010/09/17/anatomyhttp Then as near as I can tell for https: we add one round trip. – Normannormand

Answer 14

Is TLS fast yet? Yes.

• Watch: https://www.youtube.com/watch?v=0EB7zh_7UE4
• Read: https://istlsfastyet.com/

There are many projects out there that aim to blur the lines and to make HTTPS just as fast. Like SPDY and mod-spdy.

Productive

Answer 15

There seems to be a nasty edge case here: Ajax over congested wifi.

Ajax usually means that the KeepAlive has timed out after say 20 seconds. However, the wifi means that the (ideally fast) ajax connection has to make multiple round trips. Worse, the wifi often loses packets, and there are TCP retransmits. In this case, HTTPS performs really really badly!

Cully

Answer 16

HTTP VS HTTPS PERFORMANCE COMPARISON

I have always associated HTTPS with slower page load times when compared to plain old HTTP. As a web developer, web page performance is important to me and anything that will slow down the performance of my web pages is a no-no.

In order to understand the performance implications involved, the diagram below gives you a basic idea of what happens under the hood when you make a request for a resource using HTTPS.

As you can see from the diagram above, there are a few extra steps that need to take place when using HTTPS compared to using plain HTTP. When you make a request using HTTPS, a handshake needs to occur in order to verify the authenticity of the request. This handshake is an extra step when compared to an HTTP request and does unfortunately incur some overhead.

In order to understand the performance implications and see for myself whether or not the performance impact would be significant, I used this site as a testing platform. I headed over to webpagetest.org and used the visual comparison tool to compare this site loading using HTTPS vs HTTP.

As you can see from Here is Test video Result using HTTPS did have an impact on my page load times, however the difference is negligible and I only noticed a 300 millisecond difference. It's important to note that these times depend on many factors, such as computer performance, connection speed, server load, and distance from server.

Your site may be different, and it is important to test your site thoroughly and check the performance impact involved in switching to HTTPS.

Simian

In general the example is good but it is more involved than depicted, especially with Perfect Forward Secrecy. Also there are actually four symmetric keys in use. – Gorgonian

Answer 17

This is almost certainly going to be true given that SSL requires an extra step of encryption that simply isn't required by non-SLL HTTP.

Housebreaking

That there is a difference in performance between the two cases. – Bensen

But the quesiton is "Are there any major differences in performance between http and https?" – Parturition

Answer 18

HTTPS has encryption/decryption overhead so it will always be slightly slower. SSL termination is very CPU intensive. If you have devices to offload SSL, the difference in latencies might be barely noticeable depending on the load your servers are under.

Dun

Answer 19

There is a way to measure this. The tool from apache called jmeter will measure throughput. If you set up a large sampling of your service with jmeter, in a controlled environment, with and without SSL, you should get an accurate comparison of the relative cost. I would be interested in your results.

Sopping

Answer 20

Browsers can accept HTTP/1.1 protocol with either HTTP or HTTPS, yet browsers can only handle HTTP/2.0 protocol with HTTPS. The protocol differences from HTTP/1.1 to HTTP/2.0 make HTTP/2.0, on average, 4-5 times faster than HTTP/1.1. Also, of sites that implement HTTPS, most do so over the HTTP/2.0 protocol. Therefore, HTTPS is almost always going to be faster than HTTP simply due to the different protocol it generally uses. However, if HTTP over HTTP/1.1 is compared with HTTPS over HTTP/1.1, then HTTP is slightly faster, on average, than HTTPS.

Here are some comparisons I ran using Chrome (Ver. 64):

HTTPS over HTTP/1.1:

• 0.47 seconds average page load time
• 0.05 seconds slower than HTTP over HTTP/1.1
• 0.37 seconds slower than HTTPS over HTTP/2.0

HTTP over HTTP/1.1

• 0.42 seconds average page load time
• 0.05 seconds faster than HTTPS over HTTP/1.1
• 0.32 seconds slower than HTTPS over HTTP/2.0

HTTPS over HTTP/2.0

• 0.10 seconds average load time
• 0.32 seconds faster than HTTP over HTTP/1.1
• 0.37 seconds faster than HTTPS over HTTPS/1.1

Actinometer

Answer 21

The HTTPS indeed affects page speed...

The quotes above reveal the foolishness of many people about site security and speed. HTTPS / SSL server handshaking creates an initial stall in making Internet connections. There’s a slow delay before anything starts to render on your visitor’s browser screen. This delay is measured in Time-to-First-Byte information.

HTTPS handshake overhead appears in Time-to-First-Byte information (TTFB). Common TTFB ranges from under 100 milliseconds (best-case) to over 1.5 seconds (worst case). But, of course, with HTTPS it’s 500 milliseconds worse.

Roundtrip, wireless 3G connections can be 500 milliseconds or more. The extra trips double delays to 1 second or more. This is a big, negative impact on mobile performance. Very bad news.

My advice, if you're not exchanging sensitive data then you don't need SSL at all, but if you do like an ecommerce website then you can just enable HTTPS on certain pages where sensitive data is exchanged like Login and checkout.

Source: Pagepipe

Bignoniaceous

Answer 22

A more important performance difference is that an HTTPS session is ketp open while the user is connected. An HTTP 'session' lasts only for a single item request.

It you are running a site with a large number of concurrent users, expect to buy a lot of memory.

Dufy

Non in HTTP 1.1. Connections are left open for a long time. – Parturition