近期一直在和朋友讨论前端性能优化的问题，着重聊到了图片相关的优化，就想着总结记录一下。
说到图片优化主要从两个点入手，分别是优化体积和合并请求，下面我分别展开说下这两点。
优化体积
就优化体积来说，方法还是比较有限，无外乎压缩图片大小，根据视图需要选择合适的图片尺寸。
图片压缩
我们知道图片是有很多格式的，包括jpg、png、gif等，单就大小来说有损压缩的jpg格式一般是会比无损压缩的png要小的多的，但是它不支持透明；且单就png来说还区分png8、png24、png32，我们需要根据自身业务使用场景选择最优的格式，当然如果支持webp的话webp一定是最优解。
尺寸选择
选择尺寸就更好理解了，比如视图是一个固定400*300的区域，你肯定不需要放一个4000*3000的图片上去，当然现代的前端项目或多或少都需要考虑不同端的适配，我这边的处理方式是通过公司私有的图片服务器处理，你只需要上传一张原图，获取图片时根据需要带长宽参数即可获得相应大小的图片。
请求合并（针对小图或icon）
请求合并是前端优化的必要手段，不止是针对图片，这里我只列举针对图片优化的方案，当然每种方案都有他的弊端。
1. 雪碧图
用雪碧图来合并多张小图片的方案已经有很多年了，它成本低兼容好，确实能解决不少问题，但是使用雪碧图同时会带来一些副作用需要我们解决。
首先就是内存问题，由于我们把多张图片合并成一张大图，所以渲染时每次都会加载整张雪碧图，这样对于内存的开销来说实际上是更大的，解决的办法就是尽量减少图片间的留白，以及控制一张雪碧图的内容不要太多。
还有就是缩放的问题，我们都知道background-size是针对整张图片的缩放，在移动端适配多尺寸时再使用固定的px定位就会出现偏差，一般这个时候我们都会使用百分比或者rem的方式来处理，不过在部分机型上还是会出现边缘的情况，一个朋友提出了transform的解决方案，不过笔者目前还没有验证。
2. toDataUrl
toDataUrl的方案相比于雪碧图晚了些，它可以通过base64字符串来描述图片本身从而减少图片的请求；它所带来的问题是会增大体积页面本身文件大小，而且由于是内联字符串会导致图片无法缓存。
3. iconfont/svg/CSS
最后就是通过iconfont/svg/CSS等方式来模拟图片展示，这个方案可以算是是最通用的兼容最好的方案，但是也不是绝对的完美方案；就iconfont来说只能是纯色的，不能像图片那样颜色丰富，而svg和css或多或少都有一些兼容性问题。
写在最后
我们在优化图片的时候还可以设置一些缓存策略以及根据业务场景使用一些懒加载的策略，因为这两条属于所有请求通用的方案，这里就不展开说了。最后说一句我们在进行前端优化时需要根据自身需要定制优化方案，切不可为了优化而盲目优化。
