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

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

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

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

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

HTTPS requires an initial handshake which can be very slow. The actual amount of data transferred as part of the handshake isn't huge (under 5 kB typically), but for very small requests, this can be quite a bit of overhead. However, once the handshake is done, a very fast form of symmetric encryption is used, so the overhead there is minimal. Bottom line: making lots of short requests over HTTPS will be quite a bit slower than HTTP, but if you transfer a lot of data in a single request, the difference will be insignificant.

然而，keepalive是HTTP/1.1的默认行为，所以你会在同一个连接上进行一次握手，然后进行多次请求。这对HTTPS产生了重大影响。您可能应该对站点进行概要分析(正如其他人建议的那样)以确保这一点，但我怀疑性能差异不会很明显。

有一种方法可以衡量这一点。来自apache的jmeter工具将测量吞吐量。如果您在受控环境中使用jmeter对您的服务进行了大量采样，无论是否使用SSL，都应该得到相对成本的准确比较。我对你的结果很感兴趣。

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

HTTP和HTTPS性能比较

与传统的HTTP相比，我总是将HTTPS与较慢的页面加载时间联系起来。作为一个网页开发人员，网页性能对我来说很重要，任何会降低我网页性能的东西都是禁忌。

为了理解所涉及的性能影响，下面的图向您提供了使用HTTPS对资源发出请求时的基本概念。

从上图中可以看出，与使用普通HTTP相比，使用HTTPS需要执行一些额外的步骤。当您使用HTTPS发出请求时，需要进行握手以验证请求的真实性。与HTTP请求相比，这个握手是一个额外的步骤，不幸的是会引起一些开销。

为了理解性能影响并亲自查看性能影响是否显著，我使用这个站点作为测试平台。我访问了webpagetest.org，并使用可视化比较工具来比较使用HTTPS和HTTP加载的站点。

正如您可以从这里看到的测试视频结果使用HTTPS确实对我的页面加载时间有影响，但差异是可以忽略不计的，我只注意到300毫秒的差异。需要注意的是，这些时间取决于许多因素，如计算机性能、连接速度、服务器负载以及与服务器的距离。

您的站点可能有所不同，因此彻底测试您的站点并检查切换到HTTPS所涉及的性能影响非常重要。

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

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