这一次，专门制作了一个网页，加载50个完全不同的小图片，50张图片总体积195K，我们来测试一下实际的加载速度，是否能够体现HTTP2的多路复用的优势？下列表格右边的“https的图片”，都是https的链接，测试网页也是https的链接。

gtmetrix.com的Fully Loaded Time(完全加载时间)对比：

	http的多图片	https的多图片
第1次	0.6s	0.6s
第2次	0.6s	0.6s
第3次	0.5s	0.6s
第4次	0.5s	0.6s
第5次	0.5s	0.6s
第6次	494ms	0.6s
第7次	0.5s	0.6s
第8次	0.6s	0.7s

为了提高精确度，这次做了8次测试。每次都是先测试完http，再立刻测试https，间隔不到10秒钟，所以可以大致排除网络因素。每次测试中，无论是HTML传输、还是大量小图片，https没有一次跑分超过http的。

结论：现阶段，https的速度无法超过http。如果您的网页用https访问很快，那么用http会更快一点。https现阶段的瓶颈在于，SSL的hash算法过于复杂。

但值得庆幸的是，https的访问速度没有比http减少多少，因此在需要https的场合下，可以放心投入使用。但如果在高并发场合，用http会有更高的稳定性。比如在flickr成名之前，有个很早的pbase.com。pbase.com是个照片发布站，上面有大量的数码相机各个型号的样图，如今这个网站以http为主，登录页用https。因为对于高并发的场合，https会损耗很多资源和流量。

在这次的多路复用测试中，服务器环境是Ubuntu+Apache+PHP，Apache只开了默认的10个进程，但是加载图片同样很快。

再测试一张195K左右的图片的加载速度，图片实际为194K，跑分如下：

	http的单图片	https的单图片
第1次	332ms	455ms
第2次	391ms	0.5s
第3次	347ms	443ms
第4次	346ms	446ms
第5次	364ms	468ms

https链接的单张图片加载速度，仍然比http慢。与第1个表格对比，同样体积的1张图片，和50张小图片，多张的加载时间约是单张的1.5倍。

结论：http下的多张图片的加载速度还是相当快的。