对此有一个非常简单的答案:分析您的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.

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

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

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

因为我正在为我的项目调查同样的问题，我发现了这些幻灯片。年长但有趣:

http://www.cs.nyu.edu/artg/research/comparison/comparison_slides/sld001.htm

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

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

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