一、jpg/jpeg

优点：有损压缩、体积小、加载快、不支持透明

有损压缩：当我们把图片体积压缩至原有体积的50%以下时，JPG仍然可以保持住60%的品质

使用场景：

适用于呈现色彩丰富的图片，在我们日常开发中，JPG 图片经常作为大的背景图、轮播图或 Banner 图出现

jpeg压缩模式：

基线模式：自上而下、当网络连接缓慢或不稳定时，其是从上往下逐渐加载完成的

渐进模式：是将图像文件分为多次扫描、首先展示一个低质量模糊的图像，随着扫描到的图像信息不断增多，每次扫描过后所展示的图像清晰度也会不断提升

渐进模式优点：是显而易见的，在网络连接缓慢的情况下，首先能快速加载出一个图像质量比较模糊的预览版本

渐进模式缺点：渐进式JPEG的解码速度会比基线的要慢一些，因为它增加了重复的检索开销。另外，通过渐进式JPEG压缩模式得到的图像文件也不一定是最小的，比如特别小的图像。所以是否要采用渐进式JPEG，需要综合考虑文件大小、大部分用户的设备类型与网络延迟。

创建渐进式jpeg：第三方工具例如imagemin/libjpeg/imageMagic等

二、png-8 png-24 png-32等

优点：无损压缩、质量高、体积大、支持透明

PNG（可移植网络图形格式）是一种无损压缩的高保真的图片格式。8 和 24，这里都是二进制数的位数。按照我们前置知识里提到的对应关系，8 位的 PNG 最多支持 256 种颜色，而 24 位的可以呈现约 1600 万种颜色。

PNG 图片具有比 JPG 更强的色彩表现力，对线条的处理更加细腻，对透明度有良好的支持。它弥补了上文我们提到的 JPG 的局限性，唯一的 BUG 就是体积太大。

PNG-8 与 PNG-24 的选择题？

什么时候用 PNG-8，什么时候用 PNG-24，这是一个问题。

理论上来说，当你追求最佳的显示效果、并且不在意文件体积大小时，是推荐使用 PNG-24 的。

但实践当中，为了规避体积的问题，我们一般不用PNG去处理较复杂的图像。当我们遇到适合 PNG 的场景时，也会优先选择更为小巧的 PNG-8。

如何确定一张图片是该用 PNG-8 还是 PNG-24 去呈现呢？好的做法是把图片先按照这两种格式分别输出，看 PNG-8 输出的结果是否会带来肉眼可见的质量损耗，并且确认这种损耗是否在我们（尤其是你的 UI 设计师）可接受的范围内，基于对比的结果去做判断。

使用场景：

前面我们提到，复杂的、色彩层次丰富的图片，用 PNG 来处理的话，成本会比较高，我们一般会交给 JPG 去存储。

考虑到 PNG 在处理线条和颜色对比度方面的优势，我们主要用它来呈现小的 Logo、颜色简单且对比强烈的图片或背景等。

此时我们再次把目光转向性能方面堪称业界楷模的淘宝首页，我们会发现它页面上的 Logo，无论大小，还真的都是 PNG 格式

svg矢量图（iconfont）

优点：文本文件、体积小、不失真、兼容性好

最经典的小图标解决方案——雪碧图（CSS Sprites）

三、webp

优点：支持有损压缩和无损压缩

WebP 像 JPEG 一样对细节丰富的图片信手拈来，像 PNG 一样支持透明，像 GIF 一样可以显示动态图片——它集多种图片文件格式的优点于一身。

WebP 的官方介绍对这一点有着更权威的阐述：

与 PNG 相比，WebP 无损图像的尺寸缩小了 26％。在等效的 SSIM 质量指数下，WebP 有损图像比同类 JPEG 图像小 25-34％。 无损 WebP 支持透明度（也称为 alpha 通道），仅需 22％ 的额外字节。对于有损 RGB 压缩可接受的情况，有损 WebP 也支持透明度，与 PNG 相比，通常提供 3 倍的文件大小。

我们开篇提到，图片优化是质量与性能的博弈，从这个角度看，WebP 无疑是真正的赢家。

缺点：兼容性差，兼容主流浏览器，谷歌兼容最好

可以使用图像编辑软件直接导出WebP格式的图像文件，或者将原有的JPEG或PNG图像转化为WebP格式。这样的转化最好使用构建工具辅助完成，比如通过npm安装webp-loader后，在webpack中进行如下配置：

loader:[
    {
        test:/\.(jpe?g|png)$/T,
        loaders:[
            'file-loader',
            'webp-loader?{quality:13}'
        ]
    }
]

这里值得注意的是，尽量不要使用低质量的JPEG格式进行WebP转化，因为低质量的JPEG中可能包含压缩的伪像，这样WebP不仅要保存图像信息，还要保存JPEG添加的失真，从而影响最终的转化效果。所以在选择转化的源图像文件时，建议使用质量最佳的。

兼容性处理：

1、一种是在前端处理浏览器兼容性的判断，可以通过浏览器的全局属性window.navigator.userAgent获取版本信息，再根据兼容支持情况，选择是否请求WebP图像格式的资源；也可以使用〈picture〉标签来选择显示的图像格式，在〈picture〉标签中添加多个〈source〉标签元素，以及一个包含旧图像格式的〈img〉标签，当浏览器在解析DOM时便会对〈picture〉标签中包含的多个图片源依次进行检测。

倘若浏览器不支持WebP格式而未能检测获取到，最后也能够通过〈img〉标记兼容显示出旧图像格式，例如：

<picture>
 <source srcset='/path/image.webp' type='image/wabp' />
 <img src="/path/image.webp" alt=""/>
</picture>

2、一种是将判断浏览器是否支持的工作放在后端处理，让服务器根据HTTP请求头的Accept字段来决定返回图像的文件格式。如果Accept字段中包含image/webp，就返回WebP图像格式，否则就使用旧图像格式（JPEG、PNG等）返回。这样做的好处是让系统的维护性更强，无论浏览器对WebP图像格式的兼容性支持发生怎样的改变，只需要服务器检查Accept字段即可，无须前端跟进相应的修改。