Browsers can accept HTTP/1.1 protocol with either HTTP or HTTPS, yet browsers can only handle HTTP/2.0 protocol with HTTPS. The protocol differences from HTTP/1.1 to HTTP/2.0 make HTTP/2.0, on average, 4-5 times faster than HTTP/1.1. Also, of sites that implement HTTPS, most do so over the HTTP/2.0 protocol. Therefore, HTTPS is almost always going to be faster than HTTP simply due to the different protocol it generally uses. However, if HTTP over HTTP/1.1 is compared with HTTPS over HTTP/1.1, then HTTP is slightly faster, on average, than HTTPS.

以下是我使用Chrome(版本64)运行的一些比较:

HTTPS over HTTP/1.1:

0.47秒的平均页面加载时间 在HTTP/1.1上比HTTP慢0.05秒 比HTTP/2.0上的HTTPS慢0.37秒

HTTP over HTTP/1.1

0.42秒的平均页面加载时间 比HTTP/1.1上的HTTPS快0.05秒 比HTTP/2.0上的HTTPS慢0.32秒

HTTPS over HTTP/2.0

平均加载时间0.10秒 在HTTP/1.1上比HTTP快0.32秒 比HTTPS/1.1快0.37秒

一个更重要的性能差异是HTTPS会话在用户连接时保持打开。一个HTTP“会话”只持续一个项目请求。

如果你正在运行一个有大量并发用户的网站，预计会购买大量内存。

开销不是由于加密造成的。在现代CPU上，SSL所需的加密是微不足道的。

造成这种开销的原因是SSL握手，它很长，并且极大地增加了HTTPS会话与HTTP会话之间所需的往返次数。

当服务器处于模拟的高延迟链接末端时，测量(使用Firebug等工具)页面加载时间。有工具可以模拟一个高延迟的链接——对于Linux，有“netem”。在相同的设置中比较HTTP和HTTPS。

延迟可以通过以下方法在一定程度上减轻:

确保您的服务器正在使用HTTP keepalives—这允许客户端重用SSL会话，从而避免了再次握手的需要 将请求的数量减少到尽可能少——通过在可能的地方组合资源(例如.js包括文件，CSS)和鼓励客户端缓存 减少页面加载的次数，例如，将不需要的数据加载到页面中(可能是隐藏的HTML元素)，然后使用client-script显示它。

除了到目前为止提到的所有内容，请记住，出于安全原因，一些(所有?)web浏览器不会将通过HTTPS获得的缓存内容存储在本地硬盘上。这意味着，从用户的角度看，在浏览器重启后，含有大量静态内容的页面加载速度会变慢，而从服务器的角度看，通过HTTPS请求静态内容的量将比通过HTTP请求的量要高。

HTTPS有加密/解密的开销，所以它总是会稍微慢一点。SSL终止是非常消耗CPU的。如果您有卸载SSL的设备，则延迟的差异可能几乎不明显，这取决于服务器所处的负载。

我可以告诉你(作为一个拨号用户)，通过SSL访问同一个页面要比通过常规HTTP慢几倍…