性能优化之图片问题

在性能优化的道路上，图片的size能够直接影响到页面的加载速度。前端在这方面也一直被设计师和产品夹在中间。从设计师的角度来看，希望图片质量越高越好，而从产品的角度来看，页面加载速度越快越好。所以我们前端工程师就被夹在了中间，需要做出一个平衡的状态。

作为前端工程师，我们会比较倾向于页面加载速度。而我负责的项目所在的网络环境，不允许我奢侈地使用图片，所以我只能想法设法绞尽脑汁地在图片上做文章。

为什么我只是说图片的问题？

因为，通过数据证明，图片的size以及数量越少（小），加载顺序越得当，比我们做的其他优化工作都要效果显著得多。

 

经过n个项目的经验积累，总结出以下的经验：

1.根据不同的平台，不同的网络，选择加载不同的格式尺寸的图片。

假如，针对一个页面的大背景图（jpg）来说，这张背景图在压缩以后还是有60K的大小。

平台	网络	图片类型
安卓	2G	小尺寸webp
安卓	非2G	正常尺寸webp
IOS	2G	小尺寸jpg
IOS	非2G	正常尺寸jpg

区分图片格式，是因为在一些平台下浏览器不支持webp格式。

区分图片尺寸，是因为在不同的网络下，达到更好的加载速度。在网络情况不太好的情况下，应该优先小尺寸的图片。

 

2.认真分析图片的重要性，给图片排个优先级顺序

这里是运用了优先级加载的方法，跟惰性加载差不多的原理。

我们需要跟产品以及设计师确认页面中优先级最高的元素。通常banner是比较重要的元素，所以这个是需要首先加载。

而通过交互才能出现的图片元素可以在出现的时候才加载或者重要元素出现后再加载。

如果通过交互才能出现的图片尺寸比较大，但又不影响用户体验，可以选择在首屏资源加载后预先偷偷地加载图片。

 

3.不要盲目使用base64图片

也许我们可能会使用base64图片，但是请不要把这个盲目加入到首屏资源里面去。我们要考虑主文档的大小。如果有很多小图标，尽量选择使用sprite图，不要使用base64，毕竟sprite图可以有缓存。

而且，通常使用sprite图的都是一些不重要的小图标，这个延迟加载也没有什么关系。

 

4.交互后才能显示的图片

如果有个翻牌的交互动画，由于安全性问题，翻牌后才能显示对应的图片结果。

在这样一个特殊的场景下，意味着在用户翻牌以前你不可以事先请求数据把结果渲染到页面上（即使你隐藏了结果）。

所以，可以在不影响首屏资源加载的情况下偷偷加载可能结果的图片。当用户进行翻牌的时候，也就不至于出现牌翻开了图片却还没加载的情况。

 

5.你可能会把一张大背景图切成N张小图一起加载

这样子会增加了几个图片的请求，需要考虑服务器是否承受得了。同时，一般浏览器的并发请求量在10个以内，这样就会造成阻塞。

而且N张图片同时加载。。。你想象一下加载时候的场景，在移动端浏览器里面，这真的就是能够提高用户体验（包括视觉问题）吗？