为了知道我们的 Web 站点性能如何，我们一般会使用 Google 的 PageSpeed Insights ，其中，我们可能经常看到如下提示：

同时，你的打分也会被下降了，如何解决这种问题呢？

Image formats

我们知道，图片一般有不同的格式，比如我们常见的 JPG，PNG 就分别属于两种不同的图片格式，通过是否对图片进行压缩，我们可以分为：

• 无压缩。不对图片数据进行压缩处理，能准确地呈现原图片。 BMP 格式就是其中之一。
• 无损压缩。压缩算法对图片的所有的数据进行编码压缩，能在保证图片的质量的同时降低图片的尺寸。 png 是其中的代表。
• 有损压缩。压缩算法不会对图片所有的数据进行编码压缩，而是在压缩的时候，去除了人眼无法识别的图片细节。因此有损压缩可以在同等图片质量的情况下大幅降低图片的尺寸。 其中的代表是 jpg。

除了是否压缩以外，还有一个大家可能经常会遇到的问题——图片是否有透明图层，例如在之前的「搭建 Cloudflare 背后的 IPv6 AnyCast 网络」中的图片，在嵌入我的文章时并不会因为背景颜色的变化而显示出一个白色的背景，这是因为图片存在「透明通道（阿尔法通道）」，常见的支持透明通道的图片格式有：PNG，PSD，JPEG XR 和 JPEG 2000，其中后两者也是 Google 推荐的图片的 next-gen formats 之二，而常见的无透明通道的则是：JPEG 啦。

除了这个之外，还有一个由 Google 牵头研发，Telegram Stickers 主力使用的文件格式——WebP。

WebP的有损压缩算法是基于VP8视频格式的帧内编码，并以RIFF作为容器格式。因此，它是一个具有八位色彩深度和以1:2的比例进行色度子采样的亮度-色度模型（YCbCr 4:2:0）的基于块的转换方案。[18] 不含内容的情况下，RIFF容器要求只需20字节的开销，依然能保存额外的 元数据(metadata)。[2] WebP图像的边长限制为16383像素。

在 WebP 的官网中，我们可以发现 Google 是这样宣传 WebP 的：

    WebP lossless images are 26% smaller in size compared to PNGs. WebP lossy images are 25-34% smaller than comparable JPEG images at equivalent SSIM quality index.

简单来说，WebP 图片格式的存在，让我们在 WebP 上展示的图片体积可以有较大幅度的缩小，也就带来了加载性能的提升。

要生成一个 WebP 图片非常简单，只需要下载 Google 提供的 cwebp 工具，并且使用：

cwebp -q 70 picture_with_alpha.png -o picture_with_alpha.webp

就可以进行转换了，转换出来的 webp 图片比原图会小不少，但是这个是单张图片，我们的目的是让站点的图片可以无痛地以 WebP 格式输出，如果我们的博客上有 100+ 张图片转换该如何操作呢？如果是更多呢？

聪明的人可以想到——我们可以写一个脚本来自动转换，或者使用一些服务器插件，比如 mod_pagespeed （可以参考之前的文章：使用 Nginx 和 mod_pagespeed 自动将图片转换为 WebP 并输出），但是这些操作都有其特定的局限性，以 mod_pagespeed 为例，假设你能流畅完成编译/安装/配置，它的转换需要以图片和站点内容在一个目录下为前提，并通过修改 URL 的方式进行转换，举例来说，你的图片地址为：

<img src="picture_with_alpha.png">

那么经过转换后的图片可能为：

<img src="picture_with_alpha.png.pagespeed.ic.uilK6vtMij.webp">

这样可以做到图片和转换后的图片分离的效果，但是这种转换我个人博客上便无法完成，为了方便配置和防止被绑死在一个博客平台上，我的博客图片被统一地放在了 https://blog-assets.nova.moe/ 地址上，这样 mod_pagespeed 便无法发挥作用了。

Polish

在 Cloudflare 中，Pro 用户可以使用到一个功能——Polish，功能描述如下：

Improve image load time by optimizing images hosted on your domain. Optionally, the WebP image codec can be used with supported clients for additional performance benefits.

如果选择了 Serve WebP Image 的话，通过 Cloudflare 的图片请求会被无缝地转换为 WebP 格式输出，同时请求头部中，会多一个名为 cf-polished 的 Header，用来 debug 转换情况。有兴趣的读者可以看一下 Cloudflare 的博文「Using Cloudflare Polish to compress images」来了解更多相关信息。

Cloudflare 的这个功能很赞，由于这个转换需要算力，所以 Polish 只提供给 Pro 用户使用，为了同样使用到类似的功能，我用 NodeJS 写了一个服务器，命名为 WebP Server，之后和 Benny 用 Golang 重写了一遍，命名为 WebP Server Go。

WebP Server Go

由于 WebP Server 和 WebP Server Go 功能类似，且由于主要在发展后者，这里直接介绍 Go 版 WebP Server 啦。

WebP Server Go 的使用方式非常简单，由于使用 Go 编写，使用者只需要下载单一文件——webp_server，创建一个 config.json 文件，内容大致如下：

{
    "HOST": "127.0.0.1",
    "PORT": "3333",
    "QUALITY": "80",
    "IMG_PATH": "/path/tohttps://blog-assets.nova.moe/pics",
    "EXHAUST_PATH": "./dist",
    "ALLOWED_TYPES": ["jpg","png","jpeg"]
}

• HOST：对于 webp server 服务来讲只需要监听 127.0.0.1 这个本机地址就可以了，稍后使用 nginx 反向代理一下，一般来说是不建议监听0.0.0.0的
• PORT：就是 webp server 服务监听的的端口号，根据自己需求修改
• QUALITY：编码的质量，一般推荐 75 ，不过使用 80 也是不错的。
• IMG_PATH：网站的根目录，根目录，根目录，一定要配置你图片 url 的根目录。
• EXHAUST_PATH：转换后的 webp 图片文件存放位置，提前创建好。
• ALLOWED_TYPES：允许转码的图片格式，目前支持这几种。

预加载

WebP Server Go 有个预加载的功能，就是提前将全部的图片资源进行一次转换，这样再次访问图片资源的时候就不必再进行转换，而直接使用已经转换后的 webp 文件即可。这相当于一次 “缓存” 。

使用 ./webp-server -jobs 1 -config config.json -prefetch 来进行一次预加载，其中 jobs 后面的数字为你 CPU 的核心数，也可以不用加默认使用全部核心。

然后 webp_server --config /path/to/config.json 即可运行 WebP Server，最后加上 Nginx 的反向代理就可以用了。

举个例子，有一张图片是 https://image.nova.moe/tsuki/tsuki.jpg，对应的图片在服务器上的存放目录为 /var/www/nova-image/tsuki/tsuki.jpg 的话，那么，配置文件中的 IMG_PATH 就是 /var/www/nova-image，同时，每次转换导出的 webp 图片会被缓存到 webp_server 同目录的 exhaust/tsuki/tsuki.webp 下，供后续访问的时候直接输出使用。

最重要的一点是——我们访问的 URL 可以完全不用改变，访客访问的依然是 https://image.nova.moe/tsuki/tsuki.jpg ，但是得到的图片格式为：image/webp，而且体积减少了不少。

而且，对于 Safari 用户来说，WebP Server 会选择直接输出原图，防止出现输出的 webp 图片不能显示的情况。

既然咱说WebP Server Go提升了网站加载的性能，咱必须得进行一次压测才能放心大胆地推荐各位食用 WebP Server Go 啦。下面得就是咱的测试数据样例。

Benchmark

10K-500K

23.3%

./webp-server -jobs 8 -config config.json -prefetch
905.41s user 9.55s system 875% cpu 1:44.49 total
src		    	dist		num
1.3G			310M		4600
63304866.png	495K		40K
40881097.jpg	495K		118K
21045662.jpg	495K		94K
67888534.png	495K		73K
50136421.jpg	495K		62K
72636668.png	495K		113K
55156014.jpg	495K		78K
76671894.png	495K		59K
64709121.png	495K		67K
78336881.jpg	495K		77K
57090512.png	494K		35K
72153105.jpg	494K		64K
62457185.png	494K		39K
44892218.png	494K		96K
39599640.jpg	494K		39K
21428544.jpg	493K		76K
65293876.jpg	493K		68K
76098632.png	493K		80K
65418239.jpg	493K		119K
17900553.jpg	493K		51K
61511853.jpg	493K		123K
77984504.png	493K		56K
54667116.jpg	493K		56K
75357235.jpg	493K		67K
21085426.jpg	492K		55K

500K-1M

14.68%

./webp-server -jobs 8 -config config.json -prefetch
1092.50s user 7.98s system 881% cpu 2:04.81 total
src				dist		num
2.4G			361M		3500
44937735.png	974K		74K
56343106.png	974K		49K
51320479.png	974K		73K
68346957.jpg	974K		112K
74882964.png	974K		150K
76640395.jpg	974K		75K
62034004.jpg	974K		110K
59897148.jpg	974K		147K
46287856.jpg	973K		68K
54674488.jpg	973K		111K
42265521.png	973K		51K
40261146.jpg	973K		135K
76815098.png	973K		77K
57095484.png	973K		99K
65354070.jpg	973K		206K
24130390.jpg	973K		121K
73753170.jpg	972K		106K
64066680.jpg	972K		92K
72175991.png	972K		49K
53402985.png	972K		114K
70710923.png	971K		63K
76242996.png	971K		63K
65736419.jpg	971K		728K
70095856.png	971K		91K
64284761.png	971K		53K
73907152.jpg	971K		101K
62120962.png	970K		85K
22003560.png	970K		76K
77293789.jpg	970K		116K
68647243.png	970K		46K
54618347.png	970K		59K
79602155.jpg	969K		120K
55491641.jpg	968K		119K
53473372.png	968K		45K
77569729.jpg	968K		69K
57420240.png	968K		61K
69798500.png	968K		74K
63487148.png	968K		47K
79687107.jpg	967K		164K
70081772.jpg	966K		129K
79623240.jpg	966K		133K
72535236.jpg	966K		160K
47680545.png	966K		162K

1M-4M

9.3%

./webp-server -jobs 8 -config config.json -prefetch
1345.73s user 10.84s system 888% cpu 2:32.64 total
src		  		dist		num
3.8G			342M		2000
73839511.png	4.1M		293K
73839511.png	4.1M		293K
66504933.png	4.1M		107K
78316050.png	4.1M		319K
74264931.png	4.1M		330K
74412671.png	4.1M		186K
77414892.png	4.1M		227K
76442741.png	4.0M		191K
71330750.png	4.0M		199K
78361206.png	4.0M		153K
68763693.png	4.0M		233K
67222487.png	4.0M		368K
68560466.png	4.0M		186K
72437850.png	4.0M		282K
67767752.png	4.0M		203K
73597995.png	4.0M		432K
71506633.png	4.0M		88K
77601042.png	4.0M		726K
77033762.png	4.0M		261K
73436647.jpg	4.0M		514K
78099751.png	4.0M		283K
73165937.png	4.0M		202K
74379006.png	4.0M		300K
79274246.png	4.0M		191K
69701132.png	4.0M		129K
67455430.jpg	3.9M		397K
73651880.png	3.9M		183K
79152655.png	3.9M		298K
73117385.png	3.9M		258K
70281950.png	3.9M		314K
68501346.png	3.9M		203K
78895125.png	3.9M		310K
70159814.png	3.9M		156K
70764048.jpg	3.9M		437K

4M-32M

6.7%

./webp-server -jobs 8 -config config.json -prefetch
916.91s user 12.03s system 888% cpu 1:44.53 total
src				dist		num
3.8G			3.8G		500
78467499.png	32M		2.8M
79620324.png	32M
74975502.png	32M		3.0M
74902740.png	31M		2.6M
77032574.png	31M		2.5M
77673519.png	30M		2.3M
77298781.png	29M		1.4M
77959551.png	27M		1.5M
69987155.png	26M		649K
74432253.png	25M		1.6M
78994948.png	25M		923K
77218195.png	24M		1.6M
72379562.png	22M		251K
77559996.png	22M		1.9M
71522636.png	22M		1.3M
78236671.png	21M		1.7M
78033540.jpg	20M		2.7M
70906047.png	19M		677K
72498744.png	19M		882K
73977640.png	19M		523K
78757823.png	18M		1.5M
71588979.png	18M		1.2M
75747535.png	17M		1.2M
71504158.png	17M		1.2M
76969768.png	17M		1.4M
77995994.png	17M		568K
75340699.png	17M		1.4M
69821163.png	16M		1.1M
70050613.png	16M		1.1M
76559411.png	15M		1.7M
76576885.png	15M		853K
75640746.png	15M		1.4M
78188732.png	15M		1.4M
73355141.png	15M		589K
75977096.png	15M		1.4M
72840608.jpg	15M		1.8M
75665779.png	14M		1.5M
77898275.png	14M		1.2M
79663534.png	13M		1.2M
76539246.png	13M		1.2M
70598104.png	13M		840K
78348611.jpg	13M		2.7M

换句话说，基本上大部分图片的压缩比都会维持下20%以下，原图越大，转换之后的文件也就越小。也就是说，原来下载10M的图片要花10秒钟，使用WebP Server Go，只需要一秒钟就够了，因为图片只有1M左右的大小。

官方网站与下载

参考阅读

• 让站点图片加载速度更快——引入 WebP Server 无缝转换图片为 WebP
• 记 Golang 下遇到的一回「毫无由头」的内存更改
• WebP Server in Rust
• 个人网站无缝切换图片到 webp
• 优雅的让 Halo 支持 webp 图片输出
• 让图片飞起来 oh-my-webp.sh ！