Stop. Just Stop. HTTPS is not faster than HTTP.

Yes, Lori has been reading the Internet again. And what she’s been seeing makes baby Lori angry. It also makes this former test designer and technology editor cry. Really, I weep at both the excuses offered for such testing and the misleading headline.

I have read no less than two contrived comparisons of “HTTPS” and “HTTP” in the last two weeks purporting to demonstrate that secure HTTP is inarguably faster than its plaintext counterpart, HTTP.

Oh, if only that were true.

See, the trick is that both comparisons (and no doubt many more will follow) are comparing secure HTTP/2 with insecure HTTP/1.1. From the aforementioned comparison: “Plaintext HTTP/1.1 is compared against encrypted HTTP/2 HTTPS”.

As we are all already aware, HTTP/2 itself is faster (by design) than HTTP/1.1 for a variety of reasons that have absolutely nothing to do with security. Multiplexing, ‘smart’ headers, and a binary bitstream all combine to provide a faster and more efficient protocol, period. While it’s likely the case that layering security (TLS or SSL) atop HTTP/2 will cause a slight degradation in performance (because math says it will), it’s not enough to drive performance down the levels we are used to seeing with HTTP/1.1, even unsecured.

Unfortunately, these results are touting as inarguable proof that HTTPS is faster than HTTP. Which is simply not true. The argument against testing HTTP/2 secure against HTTP/2 plaintext is that browsers refuse to support HTTP/2 without security, and thus there is no way to perform such a test. So a test was contrived to pretend to illustrate the differences, but in fact does not do anything of the kind.

It’s true that comparing secure HTTP/2 with insecure HTTP/2 would be passingly difficult, if not impossible. While HTTP/2 backed off its requirement for only secure connections and allows for plaintext, all the major browsers refused to support plaintext and have thus far only provided support for HTTP/2 over TLS/SSL. Even popular command line tools like curl refuse to allow insecure HTTP/2 connections. Which winds up making HTTPS the de facto standard, even though the specification doesn’t. But that doesn’t mean you can go ahead and compare the two and then make absolutely ridiculous claims based on that test that are disproven with simple mathematics.

See, let’s pretend that a web page transferred via HTTP/2 plaintext took exactly 1.2 seconds to load. Now let’s add TLS. The addition of TLS (or SSL for that matter) means there is more processing that goes on, specifically encryption and decryption of the data. Even if that takes only .3 seconds, it still means that HTTPS is a teensy bit slower than HTTP. Period. Math says so, and math is pure. It has no agenda, it doesn’t care about the results, it simply says “here it is.”

And math says if you do X and then add on Y you get Z, and Z will always be greater than X or Y.

I understand the desire to push folks toward HTTP/2, because it’s faster and it’s the first real “upgrade” we’ve had to HTTP in a really long time, but it takes time, especially when it requires a lot of upgrades and changes to infrastructure that will necessitate disruptions as everyone from app dev to ops to netops to security have to drop what they’re doing and test, deploy, and test again. And that doesn’t account for changes in modifying apps that have long been built around HTTP/1.1 and its protocol specification. HTTP/2 changes everything. And its impact spans the entire data center. While gateways mitigate the inherent difficulty and disruption stemming from migration, not everyone necessarily sees a driving need to hop on the HTTP/2 bandwagon.

The boost in performance organizations will see simply means HTTP/2 performs as its designers intended, with increased speed and efficiency. It means organizations should be planning on the app and network infrastructure upgrades necessary to migrate to support the new standard, whether that’s through HTTP gateways or not. It doesn’t mean that HTTPS is faster than HTTP.

Making demonstrably false claims to craft click bait like headlines regarding allegedly superior performance is simply unacceptable. Yes, you will almost certainly see a boost in performance if you’re moving from HTTP/1.1 to HTTP/2, even with forced security. But that does not, in any world where logic and math exist, mean that HTTPS is faster than HTTP. If you want to help organizations, help them understand how to smoothly transition from the old to the new. Provide meaningful data for them to build a business case that enables them to upgrade to the latest and greatest. Provide them the means to show that the investment in moving from HTTP/1.x to HTTP/2 will pay off in the long run.

Offer guidelines and best practices, not punchy headlines and a buried lede.