Could be that there are enough middle-boxes inspecting/manipulating plain-text traffic? And those boxes do nothing (or do less) when the traffic is encrypted?
It says in the text at the bottom (in an unfortunately not quite as obvious way) that the HTTPS connection makes use of HTTP/2, which is significantly faster, because it streams multiple resources across one connection.
This is indicative of reality. If you set up a server nowadays, it will support HTTP/2 out of the box. And major browsers will only do HTTP/2, if it’s an HTTPS connection. But yeah, it’s not inherent to it being encrypted.
I feel like it’s more because most encryption schemes also incorporate compression, it has something to do with preventing entropy-based analysis or some other cryptography black magic.
I don’t think that is the case. There is not general-purpose compression applied to HTTPS as it may leak information like auth tokens. Compression would be transport-encoding compression which is also available in HTTP.
Very cool to see. I wonder exactly why, though. That might be something cool for the site to add at the bottom.
It looks like it’s HTTP/2 (which is HTTPS-only) vs. HTTP/1.1
HTTP/2 is not HTTPS-only.
https://http2.github.io/faq/#does-http2-require-encryption
Though, wikipedia states that: “although most client implementations require it, which makes encryption a de facto requirement.”
https://en.wikipedia.org/wiki/HTTP/2
So you are kind of right.
Anyway, this site compares HTTP/2 and HTTP/1 so it is not fair HTTP vs HTTPS comparison.
Yeah, I guess it’s fair to call this “manipulation”.
I wish it was more obvious from that webpage, since yeah, HTTPS is definitely slower by itself, but it is what a current real-time measurement will likely give you.
Oh, so it’s basically “if we use more techniques to accelerate load time, load times are faster”.
