web图片优化技巧

web图片优化技巧

为什么要对图片进行优化

对于大多数前端工程师来说，图片就是ued(或者自己) 切好的图，你要做的只是把图片丢进项目中，然后用链接的方式呈现在页面上，而且我们也经常把精力放在项目的打包优化构建上，如何分包，如何抽取第三方库… 有时我们会忘了，图片才是一个网站最大头的那块加载资源(见下图)，虽然图片加载可以不阻碍页面渲染，但优化图片，绝对可以让网站的体验提升一个档次。

从图片大小开始优化

压缩图片可以使用统一的压缩工具—imagemin，它是一款可以集成多个压缩库的工具，支持jpg，png，webp等等格式的图片压缩，比如pngquant，mozjpeg等等，作为测试用途，我们可以直接安装imagemin-pngquant来尝试png图片的压缩:

jpg/jpeg压缩jpg/jpeg压缩

压缩jpg/jpeg 图片的方式与png类似，imagemin提供了两个插件：jpegtrain和mozjpeg供我们使用。一般我们选择mozjpeg，它拥有更丰富的压缩选项：

渐进式图片

注意到我们使用了progressive: true 选项，这可以将图片转换为渐进式图片，关于渐进式图片，它允许在加载照片的时候，如果网速比较慢的话，先显示一个类似模糊有点小马赛克的质量比较差的照片，然后慢慢的变为清晰的照片：

简单来说，渐进式图片一开始就决定了大小，而不像Baseline 图片一样，不断地从上往下加载，从而造成多次回流，但渐进式图片需要消耗CPU 去多次计算渲染，这是其主要缺点。当然，交错式png也可以实现相应的效果，但目前pngquant没有实现转换功能，但是ps中导出png时是可以设置为交错式的。

图片按需加载减少请求压力

IntersectionObserver提供给我们一项能力：可以用来监听元素是否进入了设备的可视区域之内，这意味着：我们等待图片元素进入可视区域后，再决定是否加载它，毕竟用户没看到图片前，根本不关心它是否已经加载了。这是Chrome51 率先提出和支持的API，而在2021 年的今天，各大浏览器对它的支持度已经有所改善(除了IE，全线崩~)：

关于IntersectionObserver介绍：https://www.jianshu.com/p/7c06669ed98e

友好展示未加载时空白

当网速慢的时候，图片还没加载完之前，用户会看到一段空白的时间，在这段空白时间，就算是渐进式图片也无法发挥它的作用，我们需要更友好的展示方式来弥补这段空白，有一种方法简单粗暴，那就是用一张占位图来顶替，这张占位图被加载过一次后，即可从缓存中取出，无须重新加载，但这种图片会显得有些千篇一律，并不能很好地做到preview 的效果。这里我向大家推荐另一种占位图做法——css渐变色背景，原理很简单，当img标签的图片还没加载出来，我们可以为其设置背景色，比如:

响应式图片的实践

一张在普通笔记本上显示清晰的图片，到了苹果的Retina 屏幕或是其他高清晰度的屏幕上，就变得模糊了。这是因为，在同样尺寸的屏幕上，高清屏可以展示的物理像素点比普通屏多，比如Retina 屏，同样的屏幕尺寸下，它的物理像素点的个数是普通屏的4 倍(2 * 2)。

响应式图片的实践-media

而通常来讲，对于背景图片，我们可以使用css的@media 进行媒体查询，以决定不同像素密度下该用哪张倍图，例如：

响应式图片的实践-srcset

那么如何处理img标签呢？我们可以使用HTML5 中img标签的srcset来达到这个效果，看看下面这段代码：

安全地使用WebP图片

WebP的优势：同样尺寸的图片，WebP能保证比未压缩过的png、jpg、gif 等格式的图片减少百分之40-70(甚至90) 的比例，且保证较高的质量，更可以支持显示动态图和透明通道。

如何兼容WebP

picture 结合source 标签，浏览器会自动根据是否支持webp格式来选择加载哪张图片，若不支持，则会显示bg.jpg，如果浏览器连picture 都不支持，那么会fallback 到默认的img图片，这是必不可少的一个选项。

对Base64Url 的反思

首先复习一下Base64 的概念，Base64 就是一种基于64 个可打印字符来表示二进制数据的方法，编码过程是从二进制数据到字符串的过程，在web 应用中我们经常用它来做啥呢——传输图片数据。HTML 中，img的src和css样式的background-image 都可以接受base64 字符串，从而在页面上渲染出对应的图片。正是基于浏览器的这项能力，很多开发者提出了将多张图片转换为base64 字符串，放进css样式文件中的“优化方式”，这样做的目的只有一个——减少HTTP 请求数。但实际上，在如今的应用开发中，这种做法大多数情况是“负优化”效果，接下来让我们细数base64 Url的“罪状”：

• 1.让css文件体积失去控制

  当你把图片转换为base64 字符串之后，字符串的体积一般会比原图更大，一般会多出接近3 成的大小，如果你一个页面中有20 张平均大小为50kb 的图片，转它们为base64 后，你的css文件将可能增大1.2mb 的大小，这样将严重阻碍浏览器的关键渲染路径：

  

• 2.让浏览器的资源缓存策略功亏一篑

  假设你的base64Url 会被你的应用多次复用，本来浏览器可以直接从本地缓存取出的图片，换成base64Url，将造成应用中多个页面重复下载1.3 倍大小的文本，假设一张图片是100kb 大小，被你的应用使用了10 次，那么造成的流量浪费将是：(100 * 1.3 * 10)-100 = 1200kb。

• 3.不利于开发者工具调试与查看

  无论哪张图片，看上去都是一堆没有意义的字符串，光看代码无法知道原图是哪张，不利于某些情况下的比对。