为了知道我们的 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
WebP的有损压缩算法是基于VP8视频格式的帧内编码[17],并以RIFF作为容器格式。[2] 因此,它是一个具有八位色彩深度和以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",
"ALLOWED_TYPES": ["jpg","png","jpeg"]
}
然后 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
图片不能显示的情况。
Afterword
写作本文时,正好是乔布斯的生日,想到之前看到的一段话。
我们很多人都想回馈社会,在这股洪流中再添上一笔。这是用我们的专长来表达的唯一方式——因为我们不会写鲍勃·迪伦的歌或汤姆·斯托帕德的戏剧。 我们试图用我们仅有的天分去表达我们深层的感受,去表达我们对前人所有贡献的感激,去为这股洪流加上一点儿什么。那就是推动我的力量。
——《史蒂夫·乔布斯传》
这世界上轮子太多,在各种开发工具的加持下造出一个没有解决任何痛点的粗糙轮子也越发简单,而专注于解决特定需求的工具只有少量沉淀,在这个 PNG/JPG 和 WebP 共存的历史背景下,希望 WebP Server Go 成为起到一个平稳过渡的工具,目前代码已经开源在https://github.com/webp-sh/webp_server_go,由于初学 Go 没多久,代码上可能还有不少欠缺考虑的地方,还望未来的使用者海涵。
https://github.com/webp-sh
https://webp.sh/
Happy Hacking!
from https://nova.moe/re-introduce-webp-server/
--------------------------------
使用 Nginx 和 mod_pagespeed 自动将图片转换为 WebP 并输出
关于 WebP 格式,Google 是这样介绍的:
WebP is a modern image format that provides superior lossless and lossy compression for images on the web. Using WebP, webmasters and web developers can create smaller, richer images that make the web faster.
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.
Lossless WebP supports transparency (also known as alpha channel) at a cost of just 22% additional bytes. For cases when lossy RGB compression is acceptable, lossy WebP also supports transparency, typically providing 3× smaller file sizes compared to PNG.
这样来看对比目前互联网上常见图片格式——PNG 和 JPG 来说,优势就很明显了,在 Google 的 PageSpeed Insights 中,对于网站的优化许多时候也会有这样一条优化建议——将图片使用 WebP 输出。
➜ du -h eado-pov.jpg
1.4M eado-pov.jpg
使用 cwebp
进行转换之后大小变为了:
➜ du -h eado-pov.webp
292K eado-pov.webp
其中转换过程如下:
Saving file 'eado-pov.webp'
File: eado-pov.jpg
Dimension: 4109 x 2229
Output: 297652 bytes Y-U-V-All-PSNR 40.17 47.73 46.92 41.53 dB
(0.26 bpp)
block count: intra4: 17345 (48.21%)
intra16: 18635 (51.79%)
skipped: 3906 (10.86%)
bytes used: header: 322 (0.1%)
mode-partition: 66470 (22.3%)
Residuals bytes |segment 1|segment 2|segment 3|segment 4| total
macroblocks: | 1%| 7%| 22%| 70%| 35980
quantizer: | 45 | 45 | 38 | 30 |
filter level: | 14 | 18 | 56 | 45 |
图片如下(以下是 eado-pov.webp
):
至少作为网页输出来说,我肉眼没有看到什么差距,而且目前 WebP 对于主流浏览器是全部兼容的:
Amongst web browsers, Google Chrome, Firefox, Opera, GNOME Web, Midori, Falkon, Pale Moon, and Waterfox natively support WebP. Microsoft Edge supports WebP through a platform extension (installed by default). Microsoft Edge doesn’t support platform extensions, including the WebP image format extension, when running in the security hardened “Application Guard” mode.
嗯,我们离一个更快的互联网又近了一步!
为了满足这样的需求,我们有一些解决方案,比如:
- 同时准备原图(PNG/JPG)和 WebP 格式图片,让 Nginx 按照请求输出对应的文件
- 不改变原有文件结构,让 Nginx 可以 On-the-fly 地将原图转换输出 WebP
注意哈,这里 On-the-fly 的意思,不是访问一个
/xxx.jpg
就会自动变成 WebP 格式的/xxx.jpg
。(对于这个需求我们还需要一些别的方法)而是让 Nginx 检查页面中的元素,发现
/xxx.jpg
,会自动将其转换为 WebP(并存放在定义好的缓存文件夹中),并在渲染页面的时候自动把/xxx.jpg
替换成xxx.jpg.pagespeed.ic.pWglov2dVZ.webp
由于图片转换这个操作对于服务来说一般没有什么压力,且「方案一」需要写一堆的 map 和 JS 比较 dirty,这里决定采用「方案二」,让服务器直接转换并输出 WebP 格式图片。而要达成方案二也有两种方式:
- 用 Openresty 并自己搓 Lua 脚本
- 使用 Pagespeed 插件
再一次,我选择使用「方案二」。
编译 ngx_pagespeed
首先确保 Nginx 有 --with-compat
编译参数,这样我们就不需要按照一些奇怪的教程让大家从头开始编译 Nginx,使用 nginx -V
确认,比如我的 Nginx 输出如下:
nginx version: nginx/1.17.4
...
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx ... --with-compat ...
如果大家使用的 Ubuntu 系统的话,系统自带的源会比较老并且没有 --with-compat
,所以这里建议参考官方方式使用官方源:
如果已经安装过 Nginx 了请备份好
nginx.conf
之后apt remove nginx nginx-common nginx-full nginx-core
echo "deb http://nginx.org/packages/mainline/ubuntu `lsb_release -cs` nginx" \
| sudo tee /etc/apt/sources.list.d/nginx.list
curl -fsSL https://nginx.org/keys/nginx_signing.key | sudo apt-key add -
sudo apt update
sudo apt install nginx
以 Ubuntu 18.04 LTS 为例,以上安装方式会安装 Nginx 1.17.4。
接下来开始编译 pagespeed:
首先安装必备环境:
sudo apt install build-essential zlib1g-dev libpcre3 libpcre3-dev unzip uuid-dev
下载 Nginx 1.17.4 源码并解压:
wget https://nginx.org/download/nginx-1.17.4.tar.gz tar xvf nginx-1.17.4.tar.gz
找到 incubator:
git clone https://github.com/apache/incubator-pagespeed-ngx.git
在 incubator-pagespeed-ngx 目录下下载 PageSpeed Optimization Libraries 并解压:
wget https://dl.google.com/dl/page-speed/psol/1.13.35.2-x64.tar.gz tar xvf 1.13.35.2-x64.tar.gz
切换到 nginx 源代码目录下开始配置编译环境:
./configure --with-compat --add-dynamic-module=../incubator-pagespeed-ngx
编译 modules:
make modules
将对应编译好的 module 放到 nginx 目录下:
sudo cp objs/ngx_pagespeed.so /etc/nginx/modules/
启用 ngx_pagespeed
在 Nginx 主配置文件(nginx.conf
)顶部加上:
load_module modules/ngx_pagespeed.so;
并且创建好缓存文件夹以便存放自动转换的图片:
sudo mkdir -p /var/ngx_pagespeed_cache
sudo chown -R www-data:www-data /var/ngx_pagespeed_cache
如果希望所有的站点都开启 PageSpeed ,可以直接在 nginx.conf
中加入以下:
# enable pagespeed module on this server block
pagespeed on;
# Needs to exist and be writable by nginx. Use tmpfs for best performance.
pagespeed FileCachePath /var/ngx_pagespeed_cache;
# Ensure requests for pagespeed optimized resources go to the pagespeed handler
# and no extraneous headers get set.
location ~ "\.pagespeed\.([a-z]\.)?[a-z]{2}\.[^.]{10}\.[^.]+" {
add_header "" "";
}
location ~ "^/pagespeed_static/" { }
location ~ "^/ngx_pagespeed_beacon$" { }
pagespeed RewriteLevel CoreFilters;
其中最后一个部分(pagespeed RewriteLevel CoreFilters;
)表示启用的优化方式,其中包括了一些基础的优化,比如:
add_head
combine_css
combine_javascript
convert_meta_tags
extend_cache
fallback_rewrite_css_urls
flatten_css_imports
inline_css
inline_import_to_link
inline_javascript
rewrite_css
rewrite_images
rewrite_javascript
rewrite_style_attributes_with_url
如果需要加入别的 Filter ,可以类似这样写:
pagespeed EnableFilters combine_css,extend_cache,rewrite_images;
所有的 Filters 列表可以参考:Configuring PageSpeed Filters,对于我们图片的转换的话,由于 PageSpeed 会自动判断是否需要转换,对于我们需要彻底转换 WebP 的需求,还需要加上几个 filter:
pagespeed EnableFilters convert_png_to_jpeg,convert_jpeg_to_webp;
重启 Nginx 之后打开页面应该就可以发现图片的 URL 已经被替换成 WebP 格式的了.
一些小问题
如果发现你的图片并没有自动被转换成 WebP 格式的话,可以在你的 URL 后面加上 ?PageSpeedFilters=+debug
,然后查看源代码,并注意源代码中图片后面的部分,在我配置的过程中遇到过以下问题:
<!--4xx status code, preventing rewriting of xxx
由于手上 Wordpress 的机器都是放在 Docker 中,前置了 Cloudflare,所以默认的回源方式会出错,这个时候需要这样配置一下,其中localhost:2404
是本地 Docker 监听地址:pagespeed MapOriginDomain "http://localhost:2404/" "https://nova.moe/";
<!--deadline_exceeded for filter CacheExtender--><!--deadline_exceeded for filter ImageRewrite-->
这个表示 PageSpeed 正在生成对应的缓存图片。
<!--The preceding resource was not rewritten because its domain (nova.moe) is not authorized-->
由于有反向代理,SSL 在 Nginx 上就已经结束,需要配置一下代理中的:proxy_set_header X-Forwarded-Proto $scheme;
并加上:
pagespeed RespectXForwardedProto on;
总结
虽然这样做可以在不(手动)改变页面元素的情况下将 JPG 和 PNG 自动转换为 WebP 输出,但是在以上实验中,需要做到站点和媒体文件使用的一个路径,换句话说,就是需要使用 Wordpress 媒体库,而 Wordpress 媒体库于我而言并不好用,无论是为了以后备份还是迁移,所以对于我的博客,所有的图片都被放在了 https://blog-assets.nova.moe/
下,在这样一个情况下就没法做到用 PageSpeed 自动 WebP 转换了,也是接下来需要优化的一个重点(图片虽然不多,但是有些图片 1.4M 实在是有点太大了)。
References
- How to Install PageSpeed Module with Nginx on Ubuntu 18.04, Ubuntu 19.04
- The preceding resource was not rewritten because its domain ($domain) is not authorized #1251
--------------
Introducing a simple WebP Server
In the previous article I’ve introduced Nginx + mod_pagespeed, which is a great tool that allows us to convert JPGs and PNGs to WebP on the fly, the converted files can be delivered by rewriting the related HTML Code.
Given the scenario I host all my images on a dedicated server (https://blog-assets.nova.moe) with Nginx for static files server, mod_pagespeed cannot perform the on-the-fly conversion at this time.
So I’ve decided to create a simple server that can convert all JPG/PNG files to WebP format without changing the URLs.
Means you can still access images with
/xxx.jpg
but the image is in WebP format and the file size of it is smaller.
With some self-learning, there is a prototype available on GitHub: n0vad3v/webp_server written with Node, ExpressJS and cwebp, and the effect of it is quite fascinating, as below.
------------------------------------------------------
用「WebP Server Go」优化你的图片
发现了一个叫作「WebP Server Go」的开源项目。
这个项目是这么介绍的:
Go version of WebP Server. A tool that will serve your JPG/PNG/BMP/SVGs as WebP/AVIF format with compression, on-the-fly.
WebP Server 的 Go 版本,旨在将您的 JPG/PNG/BMP/SVG 图片进行动态压缩并转换为 WebP/AVIF 格式。
简单地说,这是一个自动压缩图片为 WebP/AVIF 格式的工具。
在发现了「WebP Server Go」之后,我便急忙部署在服务器上运行起来,测试实际的使用效果。
安装
项目提供了 Docker 容器,使用 docker compose 就可以一键安装:
version: "3.9"
services:
webpgo:
image: webpsh/webp-server-go
environment:
- MALLOC_ARENA_MAX=1
volumes:
- ./pic:/opt/pics #本地图片路径
- ./webpgo/exhaust:/opt/exhaust #压缩后的图片缓存
- ./webpgo/metadata:/opt/metadata #压缩前后的图片元数据缓存
ports:
- 3333:3333
restart: unless-stopped
container_name: webpgo
在 volumes
挂载目录中,./pic
指的是本地存放图片的路径,需要挂载到容器中的 /opt/pics
文件夹中。假设你有张图片路径为 ./pic/myblog/test.png
,那么 WebP Server Go 压缩后的链接就是 http://example.com/myblog/test.png 。
/opt/pics
、/opt/exhaust
、/opt/metadata
是配置文件 config.json
中的默认配置,并非不可修改。参考官方 Docker 部署文档
中的说明,我们可以自定义这一配置文件,再挂载到容器中去,以对容器进行一些微调。
原始的 config.json
内容如下:
{
"HOST": "0.0.0.0",
"PORT": "3333",
"QUALITY": "80",
"IMG_PATH": "/opt/pics",
"IMG_MAP": {},
"EXHAUST_PATH": "./exhaust",
"ALLOWED_TYPES": ["jpg","png","jpeg","bmp","gif","svg","heic"],
"ENABLE_AVIF": false,
"ENABLE_EXTRA_PARAMS": false
}
通俗易懂:
- QUALITY:压缩质量,默认
80
,即 80%,有需要可以修改为 90%。 - IMG_PATH:图片路径,即映射中的
/opt/pics
,你也可以修改为./pic
,只是修改完后不要忘了同时修改docker-compose.yml
文件。这一配置项亦支持远程路径,即你可以填写http://example.com
直接从远程链接里抓图,这样就不用本地挂载图片了。 IMG_MAP:多路径。按照官方的解释
和示例,这个配置的格式是这么写的:
"IMG_MAP": {
"/anon": "/pics1",
"/soyo": "/pics2",
"/mygo": "http://example.com"
},
简单地说,
:
左边填你想要展示的路径,随便什么都行只要格式是/xxx
;右边填具体路径./pics1
或远程链接http://example.com
,多路径就生效了。只不过要注意的是,链接的格式必须为http?s://.*
,即https://
或http://
,不匹配此格式的会被忽略。- ALLOWED_TYPES:允许的图片格式。我在测试的时候发现,如果已经是
WebP
格式,程序就会报错。本想向官方提 Issue,但试着在格式中添加了webp
,程序就不报错了,会直接使用已存在的WebP
格式图片。
其他部分都没有改动的必要,如果你有需求可以详细参考官方文档自行修改。
修改后的 config.json
保存到本地:
{
"HOST": "0.0.0.0",
"PORT": "3333",
"QUALITY": "90",
"IMG_PATH": "/pic",
"IMG_MAP": {
"/anon": "/pics1",
"/soyo": "/pics2",
"/mygo": "http://example.com"
},
"EXHAUST_PATH": "./exhaust",
"ALLOWED_TYPES": ["jpg","png","jpeg","bmp","gif","svg","webp","heic"],
"ENABLE_AVIF": false,
"ENABLE_EXTRA_PARAMS": false
}
再挂载到容器内部即可。
于是,docker-compose.yml
也跟着改动:
version: "3.9"
services:
webpgo:
image: webpsh/webp-server-go
environment:
- MALLOC_ARENA_MAX=1
volumes:
- ./webpgo/config.json:/etc/config.json #配置文件,需提前创建
- ./pics:/pics #本地图片路径
- ./pics1:/pics1 #本地图片路径1
- ./pics2:/pics2 #本地图片路径2
- ./webpgo/exhaust:/opt/exhaust #压缩后的图片缓存
- ./webpgo/metadata:/opt/metadata #压缩前后的图片元数据缓存
ports:
- 3333:3333
restart: unless-stopped
container_name: webpgo
安装完毕后,可以使用 Nginx 进行反代 :
server {
listen 443 ssl http2;
server_name example.com;
省略SSL配置
location / {
proxy_pass http://webpgo:3333;
proxy_set_header X-Real-IP $remote_addr;
proxy_hide_header X-Powered-By;
proxy_set_header HOST $http_host;
# add_header Cache-Control 'no-store, no-cache, must-revalidate, proxy-revalidate, max-age=0';
}
access_log /home/wwwlogs/example.com.log;
}
注释掉的是一段禁用缓存的配置。鉴于自用需要缓存,所以不启用它。
接着,就可以使用 http://example.com/anon/xxx.jpg 访问到 /pics1
路径下名为 xxx.jpg
的图片了。
如果你是将图片保存在博客的 usr/upload
文件夹中,也可以直接反代这一路径:
location /usr/upload {
proxy_pass http://webpgo:3333;
proxy_set_header X-Real-IP $remote_addr;
proxy_hide_header X-Powered-By;
proxy_set_header HOST $http_host;
# add_header Cache-Control 'no-store, no-cache, must-revalidate, proxy-revalidate, max-age=0';
}
这样就可以在不改变图片链接的前提下使用 WebP Server Go。前提是你已经挂载了博客的 usr/upload
文件夹到 webpgo 中。
使用
其实安装完就可以直接开始使用了,没什么好写的东西了。但我测试时发现,这玩意还可以拿来反代任意图片,不受防盗链影响,比如 sina。
例如在 IMG_MAP
配置中写成这样:
"IMG_MAP": {
"/sina": "https://wx1.sinaimg.cn/large"
},
然后访问 http://example.com/sina/9b8c9418ly1hbsl6dpurej22fa1i01kx.jpg ,可以直接访问到 https://wx1.sinaimg.cn/large/9b8c9418ly1hbsl6dpurej22fa1i01kx.jpg 的图片!
或者是 bilibili 的视频封面:
"IMG_MAP": {
"/bili": "https://i0.hdslb.com/bfs/archive"
},
然后访问 http://example.com/bili/6d1590d19238188da23755a083eba70f415af569.jpg ,也可以直接访问 https://i0.hdslb.com/bfs/archive/6d1590d19238188da23755a083eba70f415af569.jpg !
也就是说,WebP Server Go 不仅能拿来压缩图片,还能当便捷反向(图片)代理使用!
只要服务器能下载到图片!
不过,使用 WebP Server Go 唯一的代价,就是需要你有足够大的硬盘空间来存放转换后的 WebP 图片。这大概是比较不能接受的缺点吧。
- https://docs.webp.sh/usage/usage/ ↩
- https://docs.webp.sh/usage/multipath/ ↩
- 参考官方配置:https://docs.webp.sh/usage/usage-with-binary/
- 文章列表: https://docs.webp.sh/related_articles/
「也就是说,WebP Server Go 不仅能拿来压缩图片,还能当便捷反向(图片)代理使用!」
是的,甚至还有一个 SaaS 服务可以直接使用(减少自己维护 WebP Server Go 的压力):https://webp.se/
这个东西需要有一台 vps.其实可以试着薅一薅甲骨文的免费服务器(always free).
不过AVIF 还是慎用比较好,在 Web 端没事,落地到手机端和 PC 端很容易出现不识别的情况。
--------------------------------
只部署一个 webpgo 服务吧?假如你想用 a.net 反代 a.com
"IMG_MAP": {
"/a": "https://a.com",
"/b": "https://b.com"
},
那么 nginx 反代的时候,a.net 的反代就这么写:
location / {
proxy_pass http://webpgo:3333/a/;
b.net 的反代就这么写:
location / {
proxy_pass http://webpgo:3333/b/;
---------------------
「可以自已用 WebP Server Go 反代 gravatar 吗」?
可以的,由于 Gravatar 地址类似 https://www.gravatar.com/avatar/09eba3a443a7ea91cf818f6b27607d66,没有后缀名,所以 ALLOWED_TYPES 需要写 * ,一个可用的 config.json example 如下:
{
"HOST": "0.0.0.0",
"PORT": "3333",
"QUALITY": "80",
"IMG_PATH": "/opt/pics",
"IMG_MAP": {
"/": "https://www.gravatar.com/"
},
"EXHAUST_PATH": "/opt/exhaust",
"ALLOWED_TYPES": ["*"],
"ENABLE_EXTRA_PARAMS": true
}
----------------------------------
这个其实目前还好,我们测试发现如果用 jemalloc 配合 MALLOC_ARENA_MAX=1 其实已经可以将内存使用率限制到一个比较合理的范围了,详见文档: https://docs.webp.sh/usage/usage/ 中的部分。
----------------------
----------------
No comments:
Post a Comment