5 ms·

Two questions on this (from an novice-techie pov): 1. Https is slower. From a practicality standpoint - is it that much slower to actually make a difference fr

Two questions on this (from an novice-techie pov): 1. Https is slower. From a practicality standpoint - is it that much slower to actually make a difference from a UX side of things? 2. I've implemented https on one of my sites, but in chrome, it's not full green, but appears as https with the broken lock. Any idea on what that means and how to fix it?

durkie 12y ago
re 2: you're loading mixed https and http content. open up the devtools console and it will show you what's being loaded over http.
- mappu 12y ago
  Either that, or they have a SHA-1 certificate that expires in 2016 or later - https://www.ssllabs.com/ssltest/ https://www.ssllabs.com/ssltest/ will tell you for sure.
  - dspillett 12y ago
    The cut-off isn't 2016-01-01. I have a cert using a SHA1 fingerprint which expires in June 2016 (see https://random.spillett.net/ https://random.spillett.net/) and Chrome is not currently complaining about that.
igrigorik 12y ago
re 1: see https://istlsfastyet.com/ https://istlsfastyet.com/
kijin 12y ago
If you just put a static "Hello World" webpage on a server and try to benchmark it with something generic like `ab`, yes, HTTPS appears to be several times slower than HTTP. If you put a real web application on that server, enable all the bells and whistles (keep-alive, session cache, OCSP stapling, SPDY, etc), and configure your benchmark tool to make use of those features, the performance penalty of HTTPS becomes less than 5%. And that was a couple of years ago on a relatively low-end VPS. Nowadays, the difference is probably even smaller.
- avian 12y ago
  > If you just put a static "Hello World" webpage on a server and try to benchmark it with something generic like `ab`, yes, HTTPS appears to be several times slower than HTTP. Can you suggest a benchmark tool that can be used to give a more realistic figure than `ab`? I know jmeter can do session caching, but I find its interface baffling and I can't find a pre-made configuration. I recently compared performance of my home ARM server when serving my blog through HTTP and HTTPS: https://www.tablix.org/~avian/blog/archives/2014/11/cubietruck_ssl_performance/ https://www.tablix.org/~avian/blog/archives/2014/11/cubietru...
  - kijin 12y ago
    Sorry, it's been a while since I've looked at HTTP/S benchmarking tools, so I can't say which one has the latest & greatest features. By the way, did you use `ab` with the `-k` option when you ran those benchmarks? Testing HTTPS without keep-alive is utterly meaningless, since every browser aggressively reuses HTTPS connections nowadays.
Rapzid 12y ago
TLS(The S in HTTPS) incurs at least 1 extra round trip. If the site is using crappy gear this can incur even more round trips, particularly when you're accessing the site from Windows due to TCP ack delay. Anyway, to get to your question; it can. Normally you wouldn't notice because you're close-ish to the servers and you have stuff like keep alive and TLS session caching(tickets or ID's) to mitigate the issue.. But under other circumstances such as the server being in the US and you are not in the America's the difference can be significant, particularly if session caching isn't working(or working properly) and of course on first request. You can mitigate this with geographical distributed endpoints but most sites won't bother with this.
- Animats 12y ago
  Setting up all those TLS sessions for trackers, one-pixel GIF web bugs, and ad services can add significant overhead. None of the "send it all through one pipe" schemes, such as Google is pushing, help there. Google's solutions work great for Google, whose pages load almost entirely from Googleland, but are not so great for non-walled-garden sites.
  - chrisbolt 12y ago
    Most trackers these days run asynchronously and won't noticeably affect page load time.
bad_user 12y ago
My personal blog has been exclusively on HTTPS for quite some time now. - Link: https://www.bionicspirit.com/ https://www.bionicspirit.com/ - SSL Rating: https://www.ssllabs.com/ssltest/analyze.html?d=bionicspirit.com https://www.ssllabs.com/ssltest/analyze.html?d=bionicspirit.... - Server is in Europe, here's a load test from New York: http://tools.pingdom.com/fpt/200PE/https://www.bionicspirit.com/ http://tools.pingdom.com/fpt/200PE/https://www.bionicspirit.... On nr. (1) it is not that big of a deal and for your own content SPDY can make a difference. Satellite connections are indeed problematic for HTTPS. BTW - I have insisted on having my personal blog on HTTPS because I noticed that some public networks in hotels and public places are injecting content into websites. And so for me HTTPS is a way of signing my content.
bkeroack 12y ago
This is actually quite easy to test. Create a text file called curl-format.txt: time_namelookup: %{time_namelookup}\n time_connect: %{time_connect}\n time_appconnect: %{time_appconnect}\n time_pretransfer: %{time_pretransfer}\n time_redirect: %{time_redirect}\n time_starttransfer: %{time_starttransfer}\n ----------\n time_total: %{time_total}\n Now use curl to connect to your website (or any site that supports both HTTP and HTTPS): curl -w "@curl-format.txt" -o /dev/null -s "https://mysite.com" The difference between "time_connect" and "time_appconnect" is the overhead from TLS/SSL. Usually in the ~100ms range. If you connect to the same site via HTTP those two numbers should be identical (or very close).

durkie 12y ago

re 2: you're loading mixed https and http content. open up the devtools console and it will show you what's being loaded over http.

mappu 12y ago
Either that, or they have a SHA-1 certificate that expires in 2016 or later - https://www.ssllabs.com/ssltest/ https://www.ssllabs.com/ssltest/ will tell you for sure.
- dspillett 12y ago
  The cut-off isn't 2016-01-01. I have a cert using a SHA1 fingerprint which expires in June 2016 (see https://random.spillett.net/ https://random.spillett.net/) and Chrome is not currently complaining about that.

igrigorik 12y ago

re 1: see https://istlsfastyet.com/ https://istlsfastyet.com/

kijin 12y ago

If you just put a static "Hello World" webpage on a server and try to benchmark it with something generic like `ab`, yes, HTTPS appears to be several times slower than HTTP. If you put a real web application on that server, enable all the bells and whistles (keep-alive, session cache, OCSP stapling, SPDY, etc), and configure your benchmark tool to make use of those features, the performance penalty of HTTPS becomes less than 5%. And that was a couple of years ago on a relatively low-end VPS. Nowadays, the difference is probably even smaller.

avian 12y ago
> If you just put a static "Hello World" webpage on a server and try to benchmark it with something generic like `ab`, yes, HTTPS appears to be several times slower than HTTP. Can you suggest a benchmark tool that can be used to give a more realistic figure than `ab`? I know jmeter can do session caching, but I find its interface baffling and I can't find a pre-made configuration. I recently compared performance of my home ARM server when serving my blog through HTTP and HTTPS: https://www.tablix.org/~avian/blog/archives/2014/11/cubietruck_ssl_performance/ https://www.tablix.org/~avian/blog/archives/2014/11/cubietru...
- kijin 12y ago
  Sorry, it's been a while since I've looked at HTTP/S benchmarking tools, so I can't say which one has the latest & greatest features. By the way, did you use `ab` with the `-k` option when you ran those benchmarks? Testing HTTPS without keep-alive is utterly meaningless, since every browser aggressively reuses HTTPS connections nowadays.

Rapzid 12y ago

TLS(The S in HTTPS) incurs at least 1 extra round trip. If the site is using crappy gear this can incur even more round trips, particularly when you're accessing the site from Windows due to TCP ack delay. Anyway, to get to your question; it can. Normally you wouldn't notice because you're close-ish to the servers and you have stuff like keep alive and TLS session caching(tickets or ID's) to mitigate the issue.. But under other circumstances such as the server being in the US and you are not in the America's the difference can be significant, particularly if session caching isn't working(or working properly) and of course on first request. You can mitigate this with geographical distributed endpoints but most sites won't bother with this.

Animats 12y ago
Setting up all those TLS sessions for trackers, one-pixel GIF web bugs, and ad services can add significant overhead. None of the "send it all through one pipe" schemes, such as Google is pushing, help there. Google's solutions work great for Google, whose pages load almost entirely from Googleland, but are not so great for non-walled-garden sites.
- chrisbolt 12y ago
  Most trackers these days run asynchronously and won't noticeably affect page load time.

bad_user 12y ago

My personal blog has been exclusively on HTTPS for quite some time now. - Link: https://www.bionicspirit.com/ https://www.bionicspirit.com/ - SSL Rating: https://www.ssllabs.com/ssltest/analyze.html?d=bionicspirit.com https://www.ssllabs.com/ssltest/analyze.html?d=bionicspirit.... - Server is in Europe, here's a load test from New York: http://tools.pingdom.com/fpt/200PE/https://www.bionicspirit.com/ http://tools.pingdom.com/fpt/200PE/https://www.bionicspirit.... On nr. (1) it is not that big of a deal and for your own content SPDY can make a difference. Satellite connections are indeed problematic for HTTPS. BTW - I have insisted on having my personal blog on HTTPS because I noticed that some public networks in hotels and public places are injecting content into websites. And so for me HTTPS is a way of signing my content.

bkeroack 12y ago

This is actually quite easy to test. Create a text file called curl-format.txt: time_namelookup: %{time_namelookup}\n time_connect: %{time_connect}\n time_appconnect: %{time_appconnect}\n time_pretransfer: %{time_pretransfer}\n time_redirect: %{time_redirect}\n time_starttransfer: %{time_starttransfer}\n ----------\n time_total: %{time_total}\n Now use curl to connect to your website (or any site that supports both HTTP and HTTPS): curl -w "@curl-format.txt" -o /dev/null -s "https://mysite.com" The difference between "time_connect" and "time_appconnect" is the overhead from TLS/SSL. Usually in the ~100ms range. If you connect to the same site via HTTP those two numbers should be identical (or very close).