关于javascript:悟空活动中台-基于-WebP-的图片高性能加载方案

本文首发于 vivo 互联网技术微信公众号
链接：https://mp.weixin.qq.com/s/rSpWorfNTajtqq_pd7H-nw
作者：悟地面台研发团队

挪动端网页的加载速度对用户体验极为重要，是影响页面转化率的关键因素，H5 流动页往往应用大量的图片素材来丰盛流动成果，素材加载的快慢会对用户感知造成重要的影响。

在《悟空流动中台 – H5 流动加载优化》一文中咱们提到过图片压缩也是晋升悟地面台产出 H5 页面加载性能的重要伎俩之一，对本篇将从技术选型、架构设计到计划落地，全方位的出现悟空流动中台基于 WebP 的图片高性能加载计划。

蕴含了大量图片素材的 H5 页面，出现给用户之前，至多要期待首屏加载实现；要晋升加载速度，一方面申请的响应速度要足够快，另一方面要尽量减小传输的数据量。

原始做法是：拿到图片文件后，应用图片压缩工具进行压缩，页面再引入压缩后的小体积文件；

该计划存在重大的问题：效率低下 ——须要开发者或者设计师针对每张素材图进行手动压缩、肉眼审核品质、压缩失去的文件手动上传。

咱们从 高清晰度 、 高压缩比 、 小体积 的诉求登程，最终抉择了应用 WebP 作为首选图片文件格式。

WebP 是 Google 推出的一种同时提供了有损压缩与无损压缩（可逆压缩）的图片文件格式。派生自影像编码格局 VP8，被认为是 WebM 多媒体格局的姊妹我的项目，是由 Google 在购买 On2 Technologies 后倒退进去，以 BSD 受权条款公布。

WebP 的劣势体现在它具备更优的图像数据压缩算法，能带来更小的图片体积，而且领有肉眼辨认无差别的图像品质；同时具备了无损和有损的压缩模式、Alpha 通明以及动画的个性，在 JPEG 和 PNG 上的转化成果都相当优良、稳固和对立。

相比于其余雷同大小、不同格局的压缩图像，WebP 格局的图片领有 更小的体积 以及 更高的品质，劣势非常显著。

下图是一些实测案例：

应用 WebP 对图片进行 有损压缩，在默认配置 75% 的压缩比下，能够将 PNG 图片大小压缩至原图体积的 13% 左右，JPG 图片甚至能够压缩至原图体积的 10% 左右（可参考官网测试页面)，理论效果显著。

悟地面台的素材服务架构如下图所示，在 node server 节点中，咱们集成了图片转 WebP 以及转码后文件存储的服务。

图片压缩服务实现了将用户上传的图片数据，进行 格局校验 、WebP 格局转码、 上传文件服务器 以及存储的过程。

cwebp 是 Google 官网提供的用于将 PNG、JPEG、TIFF 或原始 Y’CbCr 格局的文件压缩转换为 WebP 格局的命令行编码工具（装置办法请参考官网装置阐明）。

应用办法如下：

cwebp [options] input_file -o output_file.webp

其中 options 是压缩参数配置，蕴含是否启用无损压缩 -lossless，压缩系数 -q（0~100）等，如应用 80 的压缩系数对指标文件进行有损压缩：

cwebp -q 80 image.png -o image.webp

cwebp-bin 模块提供了 Node.js 应用 cwebp 能力进行图片压缩转码的接口，咱们的图片压缩服务引入该模块模块实现常见格局图片到 WebP 的转码。

（1）工具装置

首先须要在服务器执行下述指令以装置模块外部集成的 WebP 工具程序（libwebp-x.x.tar.gz）：

npm install --global cwebp-bin

（2）网络优化

在理论应用时，打包上线时会偶发该安装包资源申请失败的问题；为了装置过程的顺利进行，悟地面台的开发者将该安装包的 url 由原 github 下载地址改为了更加稳固的 google 官网下载地址：

// node_modules/@vivo/cwebp-bin/lib/install.js - line 14

binBuild.file(path.resolve(__dirname, '../vendor/source/libwebp-1.1.0.tar.gz'), [`./configure --disable-shared --prefix="${bin.dest()}" --bindir="${bin.dest()}"`,
  'make && make install'
]).then(() => {...}).catch(error => {...});

改为

// node_modules/@vivo/cwebp-bin/lib/install.js - line 14
var cfg = ['./configure --disable-shared --prefix="' + bin.dest() + '"','--bindir="'+ bin.dest() +'"'].join(' ');

var builder = new BinBuild()
.src('http://downloads.webmproject.org/releases/webp/libwebp-0.5.1.tar.gz')
.cmd(cfg)
.cmd('make && make install');

return builder.run(function (err) {...});

（3）图片压缩

图片压缩服务中应用以下代码调用 cwebp 工具进行原图到 WebP 的转码：

const {execFileSync} = require('child_process');
const cwebp = require('cwebp-bin');

execFileSync(cwebp, ['input.png', '-o', 'output.webp'])

通过上文咱们理解到，WebP 反对 有损压缩 和 无损压缩 两种模式，上面咱们将针对性的测试两种压缩模式的差别并选出适宜的计划。

之所以要比照有损与无损的区别，次要是思考到工夫上的效率和空间上的节约。如果在损失 20~30% 的精度后，用户的肉眼上难以辨别，那么这个精度的损失就是有意义的，因为绝对于无损压缩，有损压缩带来的体积的放大以及压缩时的效率，都比无损压缩更适宜用于企业的生产模式下。

咱们选取了特点别离为 色调繁多 、 色调较为丰盛 和 色调极为丰盛 的三张图片进行测试：

上面列出了上述图片别离应用 WebP 无损和有损压缩进行测试的样本数据。

（1）WebP 无损压缩：

execFileSync(cwebp, ['-lossless', filePath, '-o', webpPath]);

后果统计

（2）WebP 有损压缩（90% 压缩率）：

execFileSync(cwebp, ['-q', '90', filePath, '-o', webpPath]);

后果统计

依据下面两份测试数据能够得出，对于 同一张图片：

从 压缩比 角度来看，90% 压缩率的有损压缩失去的图片体积小于无损压缩产出图片体积的 20%。
从 压缩工夫 角度来看，90% 压缩率的有损压缩消耗的工夫是无损压缩 20% 以内。

对于 不同图片 ，色调 越丰盛 ，压缩破费的 工夫越长 ， 压缩比越小；甚至会呈现压缩的到的图片体积超过原图的状况（具体起因见下文）。

通过以上测试数据反映的后果来看，有损压缩 的劣势更大。

应用 WebP 有损压缩来进行图片的压缩，就不得不思考接下来的问题：WebP 压缩比设置为多少才是最佳实际？

同样的，咱们对上述图片进行了以下抽样数据比照：

（1）Webp 有损压缩（90% 压缩率）：

execFileSync(cwebp, ['-q', '90', filePath, '-o', webpPath]);

后果统计

（2）Webp 有损压缩（默认值 75% 压缩率）：

execFileSync(cwebp, ['-q', '75', filePath, '-o', webpPath]);

后果统计

为什么要拿 75% 压缩率来做比照？起因是 cwebp 有损压缩的默认压缩率是 75%，这个比例也是通常状况下官网举荐的。

然而在理论业务场景下，75% 的压缩比例并不能满足产品需要。比如说一张图片通过压缩后同时在挪动端和 PC 端应用；或图片的色调空间尤其简单等等这些状况，再通过 75% 的有损压缩，咱们察看到色调对比度显著的图片部分有含糊的状况。

通过与设计师同学一起重复的测试试验，咱们应用了 90% 的压缩率来代替默认的 75%。此时转换后的图片与原图片结构化差别值 SSIM 不会小于 0.88，视觉效果上用户根本发现不了图片曾经进行了压缩。

构造相似性指标（英文：structural similarity index，SSIM index）是一种用以掂量两张数位影像类似水平的指标。当两张影像其中一张为无失真影像，另一张为失真后的影像，二者的构造相似性能够看成是失真影像的影像品质掂量指标。相较于传统所应用的影像品质掂量指标，像是峰值信噪比（英语：PSNR），构造相似性在影像品质的掂量上更能合乎人眼对影像品质的判断。

对于 WebP 压缩品质与 SSIM 的比例关系，请参考 Google 官网阐明 WebP Compression Study。

咱们能够通过在 cwebp 的执行命令中退出 -print_ssim 选项，令压缩后果中出现 SSIM 信息：

await execFileSync(cwebp, ['-print_ssim', '-q', '90', filePath, '-o', webpPath])

执行输入信息：

咱们在测试的过程中还察看到有一些图片转换为 WebP 格局后失去文件体积比原图更大。通过查阅 Google 官网文档，得出是因为格局差别以及转码算法导致的：

WebP 的压缩率设置超过 75% 时，在遇到在遇到一些非凡编码的图片时，会调整压缩时的算法，如：

当图片的编码类型解决后发生变化时，压缩后的图片体积就会变大。比如说编码类型从索引类型变动到了真彩类型，这种场景下压缩时须要解决的像素点数就会大三倍，所以压缩图片的体积就大了。
当原图片中反复的色彩数目比拟多时，Webp 有损压缩时会依据原像素值计算出新的像素值，而压缩时重点会解决的就是反复的色彩数目，所以压缩后的图片体积天然就大了。
当原图中蕴含通明管道时，因为 Webp 并不反对灰度图带上通明通道这种类型，带上通明通道就将格局固定成了 RGBA 格局。因而导致了要保留的数据变大。

面对这个问题，咱们与设计和产品共事独特制订了相应策略：如果压缩后的文件体积大于原图，则应用原图。

在确定适合的压缩比例和压缩计划后，就能够对图片压缩服务进行整体设计，流程如下：

node 执行 cwebp 指令对图片文件进行转码；
当转码后的图片体积大于源文件时，在 WebP 图片的文件名后追加“nwebp”字符串标记，以便前端辨认；
将编码后的 WebP 文件和源文件一起上传至文件服务器，并拿到返回的 URL；
将图片名称、存储资源门路等存储至素材核心服务数据库中；
存储实现后将图片名称、存储资源门路等通过接口返回前端展现。

前端页面策略是当网页运行在反对 WebP 格局的宿主环境（如 Chrome、Android Webview 等）中时，优先应用 WebP 图片资源，在 不反对 的宿主环境中，应用 原始图片 资源。

页面首先须要判断以后宿主环境是否反对 WebP：

const supportWebP = (function () {var canvas = typeof document === 'object' ? document.createElement('canvas') : {}
  canvas.width = canvas.height = 1
  return canvas.toDataURL ? canvas.toDataURL('image/webp').indexOf('image/webp') === 5 : false
})()

后面解说了后盾图片压缩和存储服务的设计，接下来咱们来一起理解一下前端逻辑上是如何加载 WebP 图片的。其流程如下图所示：

获取图片 url 的形式有多种，咱们的需要是在图片资源加载前获取实在的图片 url，并对其进行解决，而 Vue 提供的 自定义指令 能够帮忙咱们以侵入性极小的模式的拿到指标元素的相干信息。

这里咱们应用 bind 指令进行一次性的初始化设置，在当指令第一次绑定到元素时调用，通过获取到元素关联的素材的 url，以 img 元素为例：

bind: function (el, binding) {if (el.tagName.toLowerCase() === 'img' && el.src && el.src.indexOf('data:image') === -1 && supportWebP) {
    // 通过 src 属性获取 img 元素关联的图片地址
    var _src = el.src
    // ... 对 img 的后续解决
  }
}

首先判断以后 url 中是否有素材上传时标记的“nwebp”字样，如果有则阐明该图片转为 WebP 格局后体积反而大于原图，此时无需应用 WebP 素材替换原有素材；否则，则加载体积更小的 WebP 文件代替原素材文件。

而后判断以后运行环境是否反对 WebP 格局图片的渲染，如果反对，则加载 WebP 素材资源，否则应用原文件链接。

咱们在 img 标签上增加上文定义的 v-webp 指令如下：

<img src="https://someurl" v-webp />

在 img 元素的 create 阶段，v-webp 指令被 bind 并执行定义好的 hook。

在 hook 中，咱们对于 img 元素咱们能够依据 el.src 获取到元素关联素材的 url，当判断须要采纳 WebP 格式文件时，在原素材 url 后拼接.webp，从而使得对应图片元素加载的是 WebP 编码后的素材：

// ... 对 img 的后续解决
// 带有 nwebp 标记的图片不做转换
if (_src.indexOf('nwebp') > -1) {return}
let webpSrc = ''if (_src.indexOf('.webp') > -1) {webpSrc = _src} else {webpSrc = _src + '.webp'}
el.src = webpSrc
el.onerror = function() {
  // WebP 加载失败则回退至源文件
  el.src = _src
}

对于运行环境不反对 WebP 加载的状况，则无需做任何解决，间接加载原图即可:

if (!supportWebP) {return}

对于 img 之外的元素，咱们在 v-webp 指令中传入要作为 backgroundImage 属性值的 url：

<div v-webp="https://someurl"></div>

在 hook 中，依据 binding.value 获取指令的绑定值，即图片 url，当判断须要采纳 WebP 格式文件时，在原素材 url 后拼接“.webp”结构页面用 url，否则间接应用原图 url，而后为该 DOM 元素设置内联的 backgroundImage style 即可：

if (supportWebP) {el.style.backgroundImage = 'url("' + webpSrc + '")'
} else {el.style.backgroundImage = 'url("' + binding.value + '")'
}

WebP 格局尽管长处泛滥，然而有一个重大的问题—— 兼容性 并不现实。上面咱们将从“扩大 WebP 兼容范畴”的诉求登程，摸索 前端解码 WebP 文件 的可行性。

WebP 格局尽管存在压缩率高、体积小等劣势，然而其本身并不是通用浏览器图片格式标准，像 Safari 和 FireFox 等宿主环境均没有很好的反对该格局（参考自 can i use）：

为了保障悟地面台产出的专题页在更多的浏览器中可能以更快的速度加载、渲染，咱们又向前走了一步，对 WebP 格局的纯前端解码做出了上面的摸索。

核心理念是将 WebP 图片作为传输介质，保障了页面图片数据的下载速度；在拿到 WebP 图片后，对于不反对的宿主环境，将 WebP 图片进行解码成通用的 Base64 格局进行渲染。

纯前端是否能够实现 WebP 格局到 Base64 格局的解码呢？Google 官网团队提供了 js 解码 WebP 的库—— libwebp.js；然而咱们随机筛选一些 WebP 图片理论测试下来发现性能欠佳：

该计划下 WebP 图片理论的加载工夫为 网络数据传输用时 + 解码用时，面对性能要求较高的场景，WebP 的加载速度真要受限于 JS 不善于的编解码运算能力了么？当咱们再次钻研 libwebp 的材料时，浏览到下述阐明：

webp_js 还有一个 WebAssembly 版本。

WebAssembly 作为 Web 规范，在各个浏览器均有较好的反对，兼容性远强于 WebP：

WebAssembly 能够作为 C/C++/Rust 等语言的编译指标在浏览器环境中以靠近原生的速度运行，计算性能要远远优于 JavaScript。

WebAssembly 的工作流程如下（图片来自 MDN）:

其中 胶水 JS（JS“glue”code）的作用是提供 JS 调用 wasm 能力的接口。

编译并测试 libwebp

咱们将 libwebp 编译成 wasm 文件供 JavaScript 调用，提供高速解码 WebP 的能力。具体的编译过程能够参照 libwebp/webp_js 的编译阐明，编译环境倡议应用 linux/unix，其余步骤此处不再赘述。

编译后咱们失去了 wasm 文件（gzip 压缩后体积 51kb）和胶水 js（gzip 压缩后体积 44kb），而后应用上述同样的素材进行性能测试后果如下：

由以上测试根本能够得出：

当 WebP 素材较小时，wasm 解码相绝对于纯 js 解码，能够节俭 靠近一半 工夫；
当 WebP 素材较大时，wasm 计划能够使解码速度晋升 超过 100%，且随着素材增大，晋升越显著。

有了 WebAssembly 的加持，咱们将原有图片加载流程进行了如下图所示降级：

以 img 元素为例，代码解决逻辑如下：

// 如果以后浏览器环境不反对 WebP 格局，则应用 wasm 将 WebP 文件解码为 Base64
if (supportsWebP) {el.src = webpSrc} else {
  // 应用 fetch 申请拿到 WebP 文件
  const res = await fetch(webpSrc)
  // 设置拿到的文件的编码，以合乎 wasm 解码的入参条件
  const webp_data_buffer = await res.arrayBuffer()
  const webp_data = new Uint8Array(webp_data_buffer)
  // 调用碎 wasm 编译生成的胶水 js 的解码办法，将解码后的 Base64 值作为图片素材的 url 应用
  el.src = wasmDecode(webp_data)
}

咱们结构了一个图片素材较多的 H5 专题在 Safari 中测试，成果如下（为了更好的体现加载过程，下放动图绝对理论速度均加快了 3 倍）：

1、页面元素不增加 v-webp 指令（加载图片原文件）：

2、页面元增加 v-webp 指令（前端解码 WebP）：

能够看出在不反对 WebP 的宿主中，应用了 v-webp 指令后，页面的 响应速度 （白屏工夫短）和图片 渲染速度 均有较为显著的晋升；至此，咱们曾经设计并实现了一套绝对欠缺的图片素材加载性能优化计划。

悟空流动中台从晋升 H5 页面图片加载性能的诉求登程，历经：

压缩格局抉择
压缩模式和压缩率选取
前端指令集成
晋升兼容性

等一系列伎俩，摸索出一套基于 WebP 的图片高性能加载计划，更好的赋能了 H5 流动的开发和经营。悟地面台开发团队将永不止步，继续钻研和思考，为大家带来更多的实战技巧，感谢您的浏览。

【悟空流动中台】系列往期精彩文章：
《揭秘 vivo 如何打造千万级 DAU 流动中台 – 启航篇》次要为大家讲述 vivo 流动中台的能力与翻新。
《悟空流动中台 – 微组件状态治理（上）》介绍了流动页内 RSC 组件之间的状态治理和背地的设计思路。
《悟空流动中台 – 微组件状态治理（下）》摸索平台和跨沙箱环境下的微组件状态治理。
《vivo 悟空流动中台 - 基于行为预设的动静布局计划》本文以“满屏”场景下的页面布局思考为切入点，以微组件为元素单元，提供了一种新的布局方案设计思路——基于行为预设的动静布局计划，并具体的分享了设计目标及具体实现计划。
《vivo 悟空流动中台 – 微组件多端摸索》是基于自助多端扩大，也就意味着多端微组件抉择越丰盛，内容越通用，玩法越多样，产品价值也会越高。
《悟空流动中台 – H5 流动加载优化》从进步资源申请速度，资源压缩、缓存、渲染等多种角度登程，寻找悟空流动专题加载优化计划。

更多内容敬请关注 vivo 互联网技术 微信公众号

注：转载文章请先与微信号：Labs2020 分割

关于javascript:悟空活动中台-基于-WebP-的图片高性能加载方案

一、背景

为什么要做图片加载性能优化?

二、计划选型

1、演进

2、为什么是 WebP

三、图片服务

1、素材服务

2、图片压缩

应用 cwebp 进行压缩

Node 服务应用 cwebp-bin

压缩模式选取

压缩率选取

WebP 压缩后反而比原图更大？

3、服务流程

四、页面逻辑

1、优先应用 WebP

（1）判断宿主环境是否反对 WebP

（2）素材加载

（3）应用指令获取图片 url

2、解决图片 url

（1）img 元素解决

（2）background-image 解决

五、晋升兼容性

1、WebP 的兼容性问题

2、在页面解码

（1）应用 JS 解码

（2）应用 WebAssembly 晋升解码性能

3、成果比照

六、小结

Just My Socks（注册教程内含优惠码）

关于javascript:悟空活动中台-基于-WebP-的图片高性能加载方案

一、背景

为什么要做图片加载性能优化?

二、计划选型

1、演进

2、为什么是 WebP

三、图片服务

1、素材服务

2、图片压缩

应用 cwebp 进行压缩

Node 服务应用 cwebp-bin

压缩模式选取

压缩率选取

WebP 压缩后反而比原图更大？

3、服务流程

四、页面逻辑

1、优先应用 WebP

（1）判断宿主环境是否反对 WebP

（2）素材加载

（3）应用指令获取图片 url

2、解决图片 url

（1）img 元素解决

（2）background-image 解决

五、晋升兼容性

1、WebP 的兼容性问题

2、在页面解码

（1）应用 JS 解码

（2）应用 WebAssembly 晋升解码性能

3、成果比照

六、小结

Just My Socks（注册教程 内含优惠码）

Just My Socks（注册教程内含优惠码）