HTTPS vs HTTP speed comparison

Question

Update 2013-04-25:

This is a popular question that is getting more attention than it probably should. In order to stop the spread of misinformation please read the following paragraphs and the accompanying article first:

Speed should not be a factor in deciding whether to use HTTPS or HTTP. If you need HTTPS for any part of your site (log-ins, registration, credit cards, etc), you absolutely need HTTPS for all of it, all the time.

Please read SSL is not about encryption by Troy Hunt for the reasons why.

---

I'm considered running my entire e-commerce website under https. I decided to run a crude benchmark to measure the download time of a 156KB image through https vs http because I had read that https is burdened with additional overhead from the encryption process.

Benchmark was performed using Firefox's Firebug simply by transcribing the "Waiting" and "Receiving" times (all other times are 0) to Excel from the Net panel when downloading the image from an empty cache.

My results were unexpected:

http: 11.233 seconds
Waiting     Receiving   Total 
1.56        0.88        2.44 
1.55        0.101       1.651 
1.53        0.9         2.43 
1.71        0.172       1.882 
1.9         0.93        2.83 

https: 9.936 seconds
Waiting     Receiving  Total
0.867       1.59       2.457
0.4         1.67       2.07
0.277       1.5        1.777
0.536       1.29       1.826
0.256       1.55       1.806

[Obvious] Observations from benchmark:

• The server response is faster but the download time is slower for https than http.
• https is faster overall by a significant amount (~10%).

Can anyone explain why this would happen?
Do you think a document (html,css,javascript) will give different results?
Does anyone have a better method of benchmarking downloads?

---

Here is the test image:

[test image removed]

Additional Information:

• The website is on a shared hosting account through Godaddy.com.
• If you are going to be so kind as to run your own benchmark don't add the "www" subdomain...I use the root for static content anyway.
• Uses IIS7 in Integrated Pipeline Mode.

Edit: benchmark for 1px GIF (35 bytes) below:

http: 2.666 seconds
Waiting     Receiving  Total
0.122       0.31       0.432
0.184       0.34       0.524
0.122       0.36       0.482
0.122       0.34       0.462
0.126       0.64       0.766


https: 2.604 seconds
Waiting     Receiving  Total
0.25        0.34       0.59
0.118       0.34       0.458
0.12        0.34       0.46
0.182       0.31       0.492
0.134       0.47       0.604

Results: https is still faster; though trivially in this case.

If anyone sees a flaw in my benchmark let me know so I can post better results.

So, on Godaddy shared hosting at around 6:00pm on my specific server content served over https is faster than over http.

Hardee

Are you GZipping any of the two requests? – Vernitavernoleninsk

No. Didn't think you could GZip images. – Hardee

Can you try the test with a restart of Firefox after each request, to enforce a full https handshake, just as if clients would connect from different locations? – Mantle

Sure, I'll give that a try tomorrow. However, since the users aren't restarting their browser between each request this initial handshake may not be that important. I'll research it a bit more. – Hardee

You can even set a charset on images, for example UTF-8 and the browser (at least ff) tries to remove the utf-8 encoding from the image and since it isn't utf-8 encoded the image is broken. (I found it out the hard way after a change in the configuration on my server that added the charset-header even to images) – Mellow

Here is some detailed information & comparison by Yves Lafon, one of the resident experts on HTTP(s) at the W3C, I hope it would helps. – Arterio

Answer 1

If you look at your times http has bigger waiting time and smaller receiving time. https on the other hand has smaller waiting time and bigger receiving time. I would interpret this as the http port on the shared hosting server is more busy, thus a request stays longer in the queue until is accepted by the server. Once accepted, the requests is transferred faster than https. On the https port there is less traffic on the server so the request is serviced faster but takes longer to transfer.

For any https vs. http comparison you'll have to take into account the bigger time to handshake each request for https compared with http. You should see worsening when doing many small requests.

Mantle

Thanks for the info. It makes sense. I'll do the benchmark on a 1x1 pixel gif and get back to you on the times. – Hardee

You also need to take into accoun that SSL handshake is shortened when the same client reconnects (see en.wikipedia.org/wiki/…) so to give an accurate picture you'd need to test from across a variety of client processes and machines. – Mantle

Answer 2

You may also want to take into account that HTTPS documents will almost never be cached anywhere except the users browser, so you might find that while there's little difference to an individual user, an HTTP document can be significantly quicker for large numbers of people sharing a cache. (It's still quite common in some places for ISPs to put their customers through a shared proxy cache)

If it's something that you don't mind users sharing, of course.

Cauterize

+1 An extremely good point. If HTTPS is used, a large proportion of the requests will hit the website's origin web server(s) and make the site much less scalable. With HTTP, the intermediate caches will take up a substantial amount of the load and the website will scale a lot better. – Rowen

Even if the HTTP Header's Cache-Control is set to "public" with a far future expires header? e.g. Cache-Control: public, max-age=2677884 Expires: Sat, 24 Oct 2009 20:50:14 GMT – Hardee

@David: HTTPS is HTTP tunneled through an encrypted SSL/TLS tunnel. Any HTTP attribute (like headers) are invisible to intermediates, since they cannot poke inside the encrypted SSL tunnel. – Mantle

Answer 3

I think the faster performance you're seeing over HTTPS isn't a fluke.

Notice two things about your results:

1. HTTP is always faster on the first "total" result, but slower in subsequent totals.
2. The HTTPS results are more consistent.

Modern load balancers typically enable compression while SSL is in use to aid performance. While it's true that the initial SSL handshake incurs substantial latency, the mechanisms used to maintain the session (the "resumed handshake" and symmetric encryption instead of asymmetric encryption) add only negligible latency. As a result, unless your sessions are short, you get more performance benefit from the compression than you lose from the session maintenance.

The conventional wisdom that SSL incurs substantial latency is out of date (unless your sessions are quite short). Some Google engineers wrote an article explaining how some previous assumptions about SSL are no longer true.

Jorum

Answer 4

https works as follows: First a 4-way handshake is performed (at least if i remember correctly it was 4way), here client and server agree on the symmetric encryption algorithm used later on and exchange certificates (containing public keys).

They exchange a session (key for the symmetric enc later) using publickey crypto.

Now they send messages encrypted with the session key and some encryption algorithm (3des, aes, rc4, rc5, etc). Since symmetric encryptions are not that expensive operations the differences in download time are not that big.

The fact that you have less waiting time is because you probably have less traffic on http port or less traffic at the time you did the https request compared to the http requests.

So to optimize performance you should use as few https connections as possible since the handshake is a relative expensive procedure.

Iberia

Answer 5

Are you accessing your site through a proxy? If so, you may be seeing better performance because the proxy is being bypassed or reduced to just using handling the initial CONNECT requests.

A proxy could be checking and caching content when you use HTTP - leading to reduced performance.

Cerenkov

Answer 6

The whole difference in speed is most likely due to GoDaddy enforcing HTTP Compression on their servers in an effort to conserve bandwidth, but this is something that doesn't always occur with the HTTPS style connection as it is newer and better optimized to start.

Countermand