Https hurts users far away from the server

The biggest impact you can have on your users experience is to trim down the number of connections and the size of your pages. <i>Long</i> after that you can start worrying about round-trip-times to the server.<p>This blog post is a nice example: 30 requests (ublock origin blocked another 12, with those enabled the time to load increases to a whopping 28 seconds), 2.5M transferred, 7 seconds load time. And all that for 4K payload + some images.

There is also another problem on how much and how often is Googlebot indexing your site because your site speed is one of the factors of so called Google index budget. My users are in Germany so my VPS is also in Germany to be fast for local user (~130ms for http reply), but for US Googlebot is my site slow (~420ms for http reply). So you are penalized also for this.

Yup, and that&#x27;s why for thereg we started using Cloudflare&#x27;s Railgun… with it, the connection to the servers (hosted in the UK) is &quot;bearable&quot;… without, it&#x27;s abysmal:<p>From a VPS in Sydney, with a Good Enough bandwidth:<p><pre><code> root@sydney:~# speedtest-cli 2&gt;&amp;1 | grep -e Download: -e Upload: Download: 721.20 Mbits&#x2F;s Upload: 117.89 Mbits&#x2F;s </code></pre> … doing the request through Railgun is &quot;quite bearable&quot;:<p><pre><code> root@sydney:~# .&#x2F;rg-diag -json https:&#x2F;&#x2F;www.theregister.co.uk&#x2F; | grep -e elapsed_time -e cloudflare_time -e origin_response_time &quot;elapsed_time&quot;: &quot;0.539365s&quot;, &quot;origin_response_time&quot;: &quot;0.045138s&quot;, &quot;cloudflare_time&quot;: &quot;0.494227s&quot;, </code></pre> Despite our &quot;origin&quot; server being quick enough, the main chunk of time is really &quot;bytes having to travel half the world&quot;.<p>Why does railgun help? Because this is what a user would get otherwise; the &quot;whitepapers&quot; site is hosted in the UK, and doesn&#x27;t use Cloudflare or Railgun – it only uses Cloudflare for DNS:<p><pre><code> .&#x2F;rg-diag -json http:&#x2F;&#x2F;whitepapers.theregister.co.uk&#x2F; | grep elapsed_time &quot;elapsed_time&quot;: &quot;0.706277s&quot;, </code></pre> … so that&#x27;s ~200ms more, and _on http_.<p>How much would https add, if it were done without Cloudflare&#x27;s https and Railgun? That&#x27;s easy to check, as our the whitepapers site has TLS (although admittedly not http&#x2F;2):<p><pre><code> root@sydney:~# .&#x2F;rg-diag -json https:&#x2F;&#x2F;whitepapers.theregister.co.uk&#x2F; | grep elapsed_time &quot;elapsed_time&quot;: &quot;1.559860s&quot;, </code></pre> that&#x27;s quite a huge chunk of time that Cloudfalre HTTPS + Railgun just saves&#x2F;shaves for us. Recommend it highly!

There are a couple of other things you can do with existing TLS technology that can improve your latency, e.g. using OCSP stapling, use modern crypto so browsers may use TLS false start, avoid too many ciphers or unnecessary certs in the chain to make the handshake smaller.<p>It&#x27;s a bit older, but here&#x27;s some info, much of it is still valid: <a href="https:&#x2F;&#x2F;istlsfastyet.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;istlsfastyet.com&#x2F;</a>

Presumably, cloudflare is up to its ears in NSL&#x27;s, illegal wiretaps, etc. If you care at all about mass surveillance, censorship, oppressive governments (in the US, or the location of the cloudflare proxy) you probably should look elsewhere.<p>It&#x27;s probably controversial, but I&#x27;d love to see a yellow security icon in browsers when sites are using well known https relays that can see plaintext (or are doing other obviously bad things, like running software with known zero day exploits, etc)

If you&#x27;re worried about a proprietary solution, you could host your own cache server in Australia or wherever your customers are having trouble.

I don&#x27;t understand why I need to use https on a static marketing webpage. No login stuff, no JavaScript, nothing. Just straight up HTML and CSS. Right now I need to pay about $150 every year for something that&#x27;s only used to satisfy Google PageRank (I can&#x27;t use LetsEncrypt with my hosting provider). Why?

It seems to me that it is worth considering that HTTPS is not always a panacea of goodness. We should think about two things.<p>First that almost every firewall out there right now supports https snooping via MITM. Example: <a href="https:&#x2F;&#x2F;www.paloaltonetworks.com&#x2F;features&#x2F;decryption" rel="nofollow">https:&#x2F;&#x2F;www.paloaltonetworks.com&#x2F;features&#x2F;decryption</a><p>Second, I just got back from rural China where most unblocked american webpages take between 5-15 seconds to load on my mobile phone many of them take upwards of a minute to load fully. This seems to be a fun combo of network latency, smaller than expected bandwidth, and pages using javascript with a series of different load events to display content. That dompageloaded-&gt;xmlhttprequest -&gt; onreadystatechanged chain can ad some serious time on a 500ms round trip, and that&#x27;s without talking about the css, the images, and the javascript.<p>I forgot to pay me electric bill before I flew out and it took me nearly an hour to login, push pay my bill, accept the terms, and confirm payment. I was not a happy camper.<p>It seems to me that while https is a very good thing, in some cases http and low bandwidth solutions might be worth implementing. It seems to me that one might actually want to tailor this to your audience, no one in their right mind is going to waste 5 minutes loading your web page. If they are so desperate they need to wait, they are going to hate you every minute they do it.

Funny coincidence, I was running into this exact issue earlier today. Had a customer complain about high response times from even our &#x2F;time endpoint (which doesn&#x27;t do anything except return server time) as measured by curl, and turns out it was just the TLS handshake:<p><pre><code> $ curl -o &#x2F;dev&#x2F;null -s -w &quot;@time-format.txt&quot; http:&#x2F;&#x2F;rest.ably.io&#x2F;time time_namelookup: 0.012 time_connect: 0.031 time_appconnect: 0.000 time_pretransfer: 0.031 time_total: 0.053 $ curl -o &#x2F;dev&#x2F;null -s -w &quot;@time-format.txt&quot; https:&#x2F;&#x2F;rest.ably.io&#x2F;time time_namelookup: 0.012 time_connect: 0.031 time_appconnect: 0.216 time_pretransfer: 0.216 time_total: 0.237 </code></pre> (as measured from my home computer, in the UK, so connecting to the aws eu-west region)<p>Luckily not that much of an issue for us as when using an actual client library (unlike with curl) you get HTTP keep-alive, so at least the TCP connection doesn&#x27;t need to be renewed for every request. And most customers who care about low latency are using a realtime library anyway, which just keeps a websocket, so sidesteps the whole issue. Certainly not enough to make us reconsider using TLS by default.<p>Still, a bit annoying when you get someone who thinks they&#x27;ve discovered with curl that latency from them to us is 4x slower than to Pubnub, just because the Pubnub docs show the http versions of their endpoints, wheras ours show https, even though we&#x27;re basically both using the same set of AWS regions...

One round trip over the course of the time that the user is using the same OS&#x2F;browser installation isn&#x27;t much.<p>The Cloudflare Railgun is an interesting solution, and one that could be implemented in the context of an SPA over a websockets connection. Or conceivably some other consumer of an API.

A related interesting topic is the possibility of secure cache servers that don&#x27;t break the secure channel with &quot;blind caches&quot;. Currently just a RFC draft and probably a long time from mass adoption, but nevertheless interesting.<p><a href="https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;draft-thomson-http-bc-00" rel="nofollow">https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;draft-thomson-http-bc-00</a>, and Ericsson&#x27;s article on it <a href="https:&#x2F;&#x2F;www.ericsson.com&#x2F;thecompany&#x2F;our_publications&#x2F;ericsson_technology_review&#x2F;archive&#x2F;blind-cache" rel="nofollow">https:&#x2F;&#x2F;www.ericsson.com&#x2F;thecompany&#x2F;our_publications&#x2F;ericsso...</a>

I really enjoyed the coverage of the same topic in <i>High Performance Browser Networking</i>[0]. It effectively explains the key performance influencers across various networks without being boring.<p>[0]: <a href="https:&#x2F;&#x2F;hpbn.co&#x2F;" rel="nofollow">https:&#x2F;&#x2F;hpbn.co&#x2F;</a>

&gt; In our case at Hunter, users were waiting on average 270ms for the handshake to be finished. Considering requests are handled in about 60ms on average, this was clearly too much.<p>Why? Did it hurt user engagement? Were people complaining the site was slow?

What&#x27;s wrong with the cloudflare free plan? You can host a static site on github pages with a custom domain and use the free cloudflare SSL cert.