> Well, almost, let's address the "It's not fair" whingers. The HTTPS test is faster because it uses HTTP/2 whist the HTTP test only uses HTTP/1.1. The naysayers are upset because they think the test should be comparing both the secure and insecure scheme across the same version of the protocol. Now we could do that with the old protocol, but here's the problem with doing it across the newer protocol [is that HTTP/2 over TLS]<p>This doesn't invalidate the argument that you're comparing two things and claiming you're comparing two other things prima facia. For this use-case HTTP/2 will be faster, with or without TLS (if it could be tested). Claiming that it's the TLS that's speeding up the connection, which is what you mean when you say http vs https) is just plain wrong.
It's not about fairness, it's about accuracy. You can't accurately say this is just comparing HTTP and HTTPS; it's comparing HTTP/1.1 and HTTPS/2, why can't you just say that?<p>It's especially irksome that "httpvshttps.com" complains when your browser doesn't support HTTP/2, saying the results will be inaccurate. If the site were called "http1vshttps2.com" I would agree, but it's not.
Pretty stupid article, -1 flamebait.<p>One thing I have always wondered about these waterfall comparisons is why http 1.1. is slower.
Since http 1.1 has keepalive, a browser should be able to send multiple requests upfront to the server, and the server can then stream them back. The lower limit on transfer time should therefore depend only on bandwidth.
Despite the calls of "it's not fair!", I can see what he is getting at. From the end-user perspective, it doesn't matter what the underlying technology is: if it provides a faster (and more secure) experience, it's a win.<p>If there was some huge drawback to using HTTP/2, I can see why people might cry foul, but whether they like it or not, HTTP/2 is coming, so we might as well embrace it.
IMHO, when AWS uses HTTP/2 and not HTTP/1.1 over TLS, then you can start claiming that https === HTTP/2. Until then, you've moved the goalposts well beyond what most of your peers would consider to be reasonable.<p>As a side note - what is the standard regarding multiplexing for terminating HTTP/2 proxies: i.e. how much multiplexing could make it across that boundary? Or is that a bridge we haven't crossed yet?
Fun history: does anyone remember 32-bit/33MHz bus PCI crypto accelerator cards? I remember seeing them for sale around 2000/2001 with openbsd driver support.<p><a href="https://www.google.com/search?num=100&ei=oSGRV9uAHM2OjwOPxZK4AQ&q=pci+crypto+accelerator+card&oq=pci+crypto+accelerator+card&gs_l=mobile-gws-serp.3...4023.6532.0.7152.12.12.0.0.0.0.221.1390.4j6j1.11.0....0...1c.1j4.64.mobile-gws-serp..1.10.1166...35i39j0i22i30j33i21.cjLimKjUPlQ" rel="nofollow">https://www.google.com/search?num=100&ei=oSGRV9uAHM2OjwOPxZK...</a>
Imagine how fast it would be if the browsers didn't artificially restrict HTTP2 to HTTPS only. HTTP over HTTP/2 would be faster and easier on the CPU.