HTTPS确实会影响页面速度…

上面的引用揭示了许多人在网站安全和速度方面的愚蠢。HTTPS / SSL服务器握手会在进行互联网连接时造成初始停顿。在访问者的浏览器屏幕上开始呈现任何内容之前会有一个缓慢的延迟。这个延迟是用Time-to-First-Byte信息来衡量的。

HTTPS握手开销出现在时间到第一字节信息(TTFB)中。常见的TTFB范围从低于100毫秒(最好的情况)到超过1.5秒(最坏的情况)。但是，当然，使用HTTPS时，情况要差500毫秒。

无线3G连接的往返时间可以达到500毫秒甚至更多。额外的行程会使延迟加倍，达到1秒或更长时间。这对手机性能有很大的负面影响。非常坏的消息。

我的建议是，如果你不交换敏感数据，那么你根本不需要SSL，但如果你确实喜欢电子商务网站，那么你可以在某些交换敏感数据的页面上启用HTTPS，比如登录和结账。

来源:Pagepipe

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

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

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

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

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

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

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

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

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

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

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

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

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

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