HTTPS确实会影响页面速度…

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

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

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

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

来源:Pagepipe

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

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

有一种方法可以衡量这一点。来自apache的jmeter工具将测量吞吐量。如果您在受控环境中使用jmeter对您的服务进行了大量采样，无论是否使用SSL，都应该得到相对成本的准确比较。我对你的结果很感兴趣。

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

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

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