But the other point is that https now means HTTP/2 or HTTP/1.1, where as http always mean HTTP/1.1 - so I'm not sure that's true.

Pretty much the whole point of the article is that when you say "http vs https" you are no longer just saying TLS vs no TLS. It now means something more.

HTTP 2 is pretty cool, but this is just a bad title.

> Claiming that it's the TLS that's speeding up the connection, which is what you mean when you say http vs https

But that's the entire argument he's making. It's not what I mean. When I go to my web host's sysadmins and say "I need to use https so I can use service workers," I don't mean "I need to use TLS so I can use service workers." I mean what I said. https was once defined as merely http + TLS (well, SSL), but it has now come to be a protocol/scheme that supports things that http does not. One of those, and certainly the biggest, is TLS. But there are other differences.

This is a comparison between http and https. It investigates the reason why https is faster, and makes it clear that the difference is that https means other things besides TLS.

Looked at another way, it's comparing the latest HTTPS (2) with the latest HTTP (1.1).

Looked at another other way, there are huge speed advantages that you can only get if you go with HTTPS.

You aren't guaranteed those advantages if you end up stuck with HTTPS/1.1, but that just means you're using an old stack which you should (and can) upgrade (unless you're using IIS).

Right, users see HTTP and HTTPS, they don't see /1.0 versus /1.1 versus /2.

(There's a good argument that users seeing HTTP versus HTTPS was a mistake, too, versus just secure/unsecure markers in browsers. TLS shouldn't have needed a new port number and URL prefix... but it is way too late to fix that now.)

> if it provides a faster (and more secure) experience, it's a win.

Http/2 without tls would be even faster. Had it not been for someone with an agenda deliberately saying it should not be supported.

Works for me.

It works here

SSL labs shows A+ across the board

https://www.ssllabs.com/ssltest/analyze.html?d=www.troyhunt....

Head of line blocking is mostly a theoretical concern not a practical one. Since browsers use 6+ connections at once, a large slow request will only hold up a few resources and usually doesn't affect the page load speed by much. In fact, as shown recently interleaving can actually slow down the page rendering. Then there's the priority system, an inversion of which caused Google Maps to load far more slowly over HTTP/2. The main problem solved by interleaving responses is when there are 6 slow resources that tie up all the connections causing deadlock, which is because of browsers capping the number of connections.

Google spread a lot of FUD in their push to get SPDY standardized. For instance they never compared to pipelining, which is relevant because Microsoft found that with pipelining HTTP was essentially just as fast. Google's mobile test where they claimed ~40% speedup used 1 SPDY TCP connection for the entire simulated test run of many sites vs new connections per site for HTTP -- a simple mistake? Maybe, but they didn't take any steps to correct it once they were made aware of it.

From the link

"HTTP/1.x has a problem called “head-of-line blocking,” where effectively only one request can be outstanding on a connection at a time."

Does it? Why?