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.
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.