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

要真正理解HTTPS如何增加延迟，您必须了解HTTPS连接是如何建立的。这是一个很好的图表。关键在于，客户端不是在2个“腿”(一个往返，你发送一个请求，服务器发送一个响应)后才获得数据，而是至少要到4个“腿”(2个往返)后才能获得数据。因此，如果一个数据包在客户端和服务器之间移动需要100毫秒，那么您的第一个HTTPS请求至少需要500毫秒。

当然，这可以通过重新使用HTTPS连接来缓解(浏览器应该这样做)，但它确实解释了加载HTTPS网站时的部分初始停滞。

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

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

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

目前最上面的答案并不完全正确。

正如其他人在这里指出的，https需要握手，因此需要更多的TCP/IP往返。

在WAN环境中，延迟通常成为限制因素，而不是服务器上增加的CPU使用量。

请记住，从欧洲到美国的延迟大约是200毫秒(往返时间)。

您可以使用HTTPWatch轻松地测量这一点(对于单个用户情况)。

在许多情况下，SSL握手对性能的影响将由于SSL会话可以缓存在两端(桌面和服务器)而得到缓解。例如，在Windows机器上，SSL会话可以缓存长达10个小时。见http://support.microsoft.com/kb/247658/EN-US。一些SSL加速器还具有允许您优化会话缓存时间的参数。

另一个需要考虑的影响是，通过HTTPS提供的静态内容不会被代理缓存，这可能会降低通过同一个代理访问站点的多个用户的性能。这可以通过静态内容也会缓存到桌面的事实来缓解，Internet Explorer版本6和7缓存可缓存的HTTPS静态内容，除非另有指示(工具菜单/Internet选项/高级/安全/不将加密页面保存到磁盘)。