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

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

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

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

TLS快吗?是的。

看:https://www.youtube.com/watch?v=0EB7zh_7UE4 阅读:https://istlsfastyet.com/

有许多项目旨在模糊界限，使HTTPS一样快。比如SPDY和mod-spdy。

HTTPS确实会影响页面速度…

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

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

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

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

来源:Pagepipe

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产生了重大影响。您可能应该对站点进行概要分析(正如其他人建议的那样)以确保这一点，但我怀疑性能差异不会很明显。

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

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