考虑到SSL需要一个非sll HTTP不需要的额外加密步骤，这几乎肯定是正确的。

考虑到SSL需要一个非sll HTTP不需要的额外加密步骤，这几乎肯定是正确的。

这里有一篇关于SSL握手延迟的很棒的文章(有点老，但仍然很棒)。帮助我确定SSL是客户端通过较慢的互联网连接使用我的应用程序的缓慢的主要原因:

http://www.semicomplete.com/blog/geekery/ssl-latency.html

对此有一个非常简单的答案:分析您的web服务器的性能，看看在您的特定情况下性能损失是什么。有几个工具可以比较HTTP和HTTPS服务器的性能(我想到了JMeter和Visual Studio)，而且它们很容易使用。

没有人能给你一个有意义的答案没有一些关于你的网站的性质，硬件，软件和网络配置的信息。

正如其他人所说，由于加密，会有一定程度的开销，但它高度依赖于:

硬件 服务器软件 动态与静态内容的比例 客户端到服务器的距离 典型会话长度 等等(我个人的最爱) 客户端的缓存行为

根据我的经验，动态内容较多的服务器受HTTPS的影响较小，因为与内容生成时间相比，加密所花费的时间(ssl开销)微不足道。

大量服务于相当小的静态页面集(这些页面可以很容易地缓存在内存中)的服务器会遭受更高的开销(在一个案例中，吞吐量在“内部网”上受到了影响)。

编辑:有一点已经被其他几个人提出，SSL握手是HTTPS的主要成本。这是正确的，这就是为什么“典型会话长度”和“客户端的缓存行为”很重要。

很多非常短的会议意味着握手时间将压倒其他任何表现因素。较长的会话将意味着在会话开始时产生握手成本，但后续请求的开销将相对较低。

Client caching can be done at several steps, anywhere from a large-scale proxy server down to the individual browser cache. Generally HTTPS content will not be cached in a shared cache (though a few proxy servers can exploit a man-in-the-middle type behavior to achieve this). Many browsers cache HTTPS content for the current session and often times across sessions. The impact the not-caching or less caching means clients will retrieve the same content more frequently. This results in more requests and bandwidth to service the same number of users.

HTTP和HTTPS性能比较

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

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

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

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

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

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

这里似乎有一个令人讨厌的边缘情况:Ajax胜过拥塞的wifi。

Ajax通常意味着KeepAlive在20秒后超时。然而，wifi意味着(理想的快速)ajax连接必须进行多次往返。更糟糕的是，wifi经常丢包，并且有TCP重传。在这种情况下，HTTPS执行得非常非常糟糕!