棋逢对手:background对比img_html/css_WEB-ITnose
img方法比background方法能更加快速的显示图片。
接下来个人结合日常项目需求对两者关于加载速度、FPS、动画性能等方面进行对比:
测试准备
两个demo中分别使用background-image方式和img src方式对图片展示,页面中均有500个DOM,分别对速度、FPS、动画流畅性等方面进行测试比较。
一、速度测试
测试网络情况为Regular 3g(750kb/s 100ms RTT)。 由于实现方式不同所以页面的代码体积大小是不一样的。两个测试文件中,background页面完全加载成功后是337kb,img页面完全加载成功后是347kb。 两个demo加载后的大小主要是受css和html代码影响,background页面实现方式css代码量会相对较多,html代码量较少;而img页面实现方式css代码量会相对较少,html代码量较多。所以在页面各放置了500个DOM,html的代码量剧增,最终导致img页面会比background页面大一些。 最后使用Navigation Timing API测试页面加载时间。测试代码如下:
window.onload = function() { setTimeout(function() { var t = performance.timing; console.log("页面速度: " + (t.loadEventEnd - t.responseEnd) + " ms"); }, 0);};
测试数据为(单位ms):
平均值 | |||||||||||
backgruound | 3356 | 3352 | 3350 | 3354 | 3353 | 3354 | 3353 | 3353 | 3354 | 3352 | 3353.1 |
img | 3216 | 3238 | 3224 | 3224 | 3230 | 3222 | 3225 | 3229 | 3212 | 3215 | 3223.5 |
从上面的数据可以看出background页面和img页面加载速度差异不大,再结合前面所说的“img页面会比background页面大一些”,最终我们可以得到结论: 两者加载速度差异不大。在极端情况下,img页面实现方式会稍微快一些。
二、FPS测试
两者实现方式的本质都是将图片渲染出来,在理论上来说,两者应该差别不大,但还是做了数据统计,见下表:
平均值 | |||||||||||
backgruound | 16.0 | 17.7 | 18.6 | 17.7 | 17.3 | 16.2 | 17.7 | 20 | 19.1 | 16.9 | 17.72 |
img | 19 | 16.9 | 20 | 18.5 | 19 | 16.2 | 15.7 | 17.8 | 19 | 21 | 18.31 |
从这里的数据显示得到结论:两者FPS差异不大。
三、动画性能
在两个demo页面中,使用css3的transform:rotate实现从0度到360度循环旋转动画。演示地址:
(img页面)
(background页面)
测试得到GPU数据为:
平均值 | |||||||||||
backgruound | 11 | 14 | 15 | 23 | 30 | 11.1 | 25 | 26.9 | 25 | 12 | 19.3 |
img | 6.2 | 6.2 | 6.2 | 6.2 | 6.2 | 6.2 | 6.2 | 6.2 | 6.2 | 6.2 | 6.2 |
上面数据中显示,background页面实现方式GPU使用会在0~30之间波动;img页面实现方式GPU则一直保持在6.2。在比较低端手机上体验的时候,也很明显的感受到background页面的动画会出现一些卡顿,而img页面的动画则非常流畅。从这里可以得出结论: 在动画方面,img实现方式比background实现方式性能会更好,可以提高动画性能。
总结
结合其他一些比较重要的方面,最后做个总结:
- 在对页面加载速度方面,两者差别不大;
- 做动画的时候,尽量选择使用img标签,性能会更好一些;
- 在SEO语义化方面,background完全不沾边,img语义清晰明了;
- background结合css sprite可以优化页面加载速度;
- 重要图片建议使用img标签,在页面加载时可以优先显示;
感谢大家阅读,欢迎一起探讨。