- 站在前端的角度，图片是网站不可或缺的一部分，在前端的各种性能优化的手段中，图片优化占比算是比较重的，有时候我们可能只是浅显的认为，图片优化手段无非就是图片格式，压缩，合并，缓存等一些手段，而并非对其中各个业务场景做针对性处理，或者对图片各种格式的优缺点？如雪碧图该如何使用？在某些性价比较高的图片较高而又存在兼容性问题的情况如何处理？对于同一种图片格式不同分辨率类型应该对应什么样的应用场景？等等一些问题或许还未做一些深入的研究与分析，今天主要是针对前端图片优化参考一些性能做得比较完善的网站总结出自己的一些想法，如有不合理之处，欢迎各位大佬指正。
接下来，让我们先了解一下常用的一些图片格式，以及各个图片格式适合的业务场景吧...
JPG格式：
特点：有损压缩、压缩率高、不支持透明
JPG格式想必不论是前端还是后台，对此都是特别常见的图片格式了，jpg格式的图片是一种有损压缩的图片，所谓有损压缩就是在保证用户能接受的质量范围内对图片size做减法的一种算法。
由Raw Image -> JPEG-Compressed会经过（颜色空间转化）-> (重采样来区分高频与低频的一些颜色变化) -> (DTC高频压缩) -> (数据量化) -> (Encoding) -> JPEG 一系列转化的过程。(此图来自网络)
我们什么时候选JPG呢？它适合哪些业务场景？
大家知道，JPG格式特点是：有损压缩、压缩率高、不支持透明，针对它的特点，我们一般会是在大部分不需要透明场景的情况下会选择JPG图片格式。
PNG格式：
特点：支持透明度，浏览器兼容较好
PNG格式又分为png8/png24/png32三种不同的类型，它也是我们网站中最常见不过的一种图片了格式了，PNG格式与JPG格式不同，它本身是一种颜色索引的组合。
PNG8可以理解为一种颜色索引为2的8次方来表示，也就是8bit， 相对于较复杂的图片来说，颜色渲染以PNG8可能没法表示， 支持透明；
PNG24以此类推，它是以一种颜色为2的24次方来表示颜色索引，支持更复杂的图片颜色，不支持透明；
PNG32顾名思义，它是以一种颜色为2的32次方来表示颜色索引，对图片颜色的支持更大于24，支持透明度；
3中不同类型PNG图片SIZE通过命名可以参数，按照不同类型同一种PNG格式大小是不一样的，可以针对不同的业务场景选择不同的PNG类型进行渲染以达到性能优化的目的；那么到底在什么场景下选择什么的类型呢？
通过分析，PNG8中只要8bit即可表示一种颜色，PNG24bit来表示一种颜色，PNG32为32bit来表示一种颜色并支持透明其实增加的8bit就是用来支持透明的；所以针对不同的场景，我们选择的的PNG类型可以做不同选择？
如：
看图说话，这是一片沙漠，浩瀚无边，一片金黄......然而它对颜色的要求并没有多高，当我们进行图片选择时，在保证图片质量的情况下PNG8可完全支持，当前这种场景下我们就可选择PNG8类型， 相比PNG32来，在同等效果的情况下SIZE相比在原有基础上减少75%；
而这图，花海，让人心旷神怡，美不胜收....然后如果我们用PNG8用256色来表示该图片的索引，图片相对视觉来说就会大打折扣，这里PNG24与PNG32同样都可以实现该图的色彩索引，那么什么时候选PNG24？什么时候选PNG32呢？上面分析，如果PNG24与32最大的区别就是一个支持透明，一个不支持。说到这里，大家或许一目了然了，如果我们不需要用到透明的情况下，我们必然会选择SIZE相对较小的PNG24，如果要支持透明，那就老老实实是选择32吧。
webp格式：
特点：有损压缩，压缩程度更好，在同等压缩比的情况下相比JPG的SIZE要少30%左右。
业界评测，webp格式算法压缩率以及质量都是高于JPG的，存在浏览器兼容性问题，在IOS浏览器与webView中支持不是很好，android系统现在基本都已支持；
下图是某宝的应用场景，通过图片动态化处理，对支持webp的环境环境统一使用webp格式
1、节省了宽带资源
2、更快的加载速度，提升用户体验
应用场景：通过图片动态处理，在android设备或者支持webp格式的环境中我们尽量使用webp格式；
SVG矢量图：
特点：相对较小，不占用网络资源，内嵌DOM中，不占用http请求资源，所以能用这个尽量这个；
由于SVG图片是嵌入我们的DOM结构中，我们可以理解为它就是一段html代码，当DOM结构加载完成，它同时就可以渲染出来，速度快，并不会单独发起http请求
适用于小图标的业务场景，某宝www.iconfont.cn/矢量图库就是针对这一点来做细节的性能优化。
在我们的所看到的页面中，图标很多，但并没有过多的http图片请求，大家设想一下，如果一个一条http请求，同域情况下浏览器会对发起http请求并发数限制，
以chrome为例，为6条，上图这么多图片，将会占用更多的宽带资源与影响用户体验，SVG就成了我们一个最好的选择。
应用场景：平时在页面中一些小ICON或者log等一些简单的图标，我们可以用SVG；
或许大家针对SVG图片同时占用并发链接以及宽带资源想到了雪碧图的方案，一张图不就解决了吗？
雪碧图是一个资源合并，确实可以提升性能，但它适合什么样的场景，使用时是不是全部合到一张图就OK，或者还存在一些什么其它问题？
像facebook、Twitter、google这样的全球企业他们针对图片资源又做了些怎么样的处理？
前端性能之图片优化（二）后续将推出......敬请关注。
