It's been a long time since I paid attention to WebP support. At first glance, it seems that even QQ Browser can perfectly support WebP now. I have been paying attention to WebP-Server, a transition tool, for a long time. Recently, my friend gave me a Tencent Cloud Light server, so I decided to deploy it on a lightweight server in China to experience the improvements brought by WebP.
1. Overview#
WebP is an efficient image compression solution developed by Google (Google WebP). Compared to lossless PNG, WebP generally achieves a compression ratio of up to 75% with 20% lossy compression. As Google promotes, WebP's compression rate is usually 30% higher than JPEG and JPEG 2000 on average, without reducing image quality.
%3Fvalid%3Dfalse%26imageUrl%3Dhttps%253A%252F%252Fmoe.lty.fun%252Fimages%252FJfFa.png&w=3840&q=75)
However, until 2023, pure WebP storage still faces significant historical legacy issues. In terms of accessibility, the problem is relatively small, as only Safari before iOS 14 does not support it. Both mainstream modern browsers in China and abroad already support the loading of WebP images (support statistics). However, various productivity tools, such as Ps and Ai, still do not support loading WebP images. If the original image is only saved as WebP, it means giving up a small part of old devices and losing the convenience of editing. On one hand, WebP brings an ultimate media loading experience, on the other hand, it loses some editing convenience. I used to struggle with these trade-offs and was hesitant to adopt new technologies because I couldn't solve the problem perfectly.
Recently, my friend mentioned the WebP-Server transition tool by chance. This is a WebP conversion middleware based on the Go language. Like many CDN-provided transition strategies, it can determine whether to return WebP or the original image based on the visitor's user agent (UA) to judge browser support. Similarly, WebP-Server can also support generating WebP caches and compressing requests to the origin server as an edge access node like a CDN.
- Project homepage: https://webp.sh
- Project documentation: https://docs.webp.sh/usage/basic-usage
- GitHub: https://github.com/webp-sh/webp_server_go
Looking at our domestic server market, the maximum bandwidth that can be afforded within the scope of personal economic capacity is only about 4-5M. Based on this assumption, we can theoretically calculate that 5M bandwidth can provide you with a transmission capacity of approximately 640k/s. Based on my experience, an average of 8 images per page, 100k/image, will fill the bandwidth in 1.25 seconds to complete the image loading. However, in the case of 20% lossy WebP compression, the average image size is reduced to 16-25k, which can increase the PV concurrency capacity by 5 times within 1 second. This significantly improves the site's load capacity in the Chinese network environment where server bandwidth is very limited. Based on this situation, if a self-used image hosting service can be configured with WebP, it is likely that there is no need to pay extra for a CDN and can provide services through high-quality BGP networks.
In the post-pandemic environment of reducing costs and increasing efficiency, only Tencent Cloud's "April Cloud Selection" still provides three-year 408 2C/2G/4M and 628 2C/4G/5M lightweight application servers. Recently, my friend gave me a Tencent Cloud Light server, which has a configuration of 1C/2G/5M, which is basically the same as the bandwidth of the promotional version. By the way, Tencent Cloud has opened a paid upgrade channel for the Light server. If you have a Light server, you can choose to upgrade to a higher configuration as needed.
2. WebP Server#
Since WebP-Server requires the libaom component and requires libc6>2.34, I recommend using CentOS 8 / Debian 11 or later systems. Although earlier systems can upgrade the libc6 version through compilation, this is a very dangerous operation that may cause problems with critical system components. Therefore, for earlier systems, I recommend using Docker for deployment (official documentation), which supports ARMv7 (32-bit), ARM64 (Aarch64), and AMD64 (x86-64). You can check it on DockerHub (click to go).
# [/path/to/pics] refers to the image path, [/opt/pics] refers to the generated WebP cache path
docker run -d -p 3333:3333 -v /path/to/pics:/opt/pics --name webp-server webpsh/webp-server-go
If you want to install it manually, the necessary component is libaom3. This component is a bit tricky. The precompiled package will default to read libaom.so.3 this .so. After installation, if you still get a prompt that libaom3 cannot be found, you can try creating a symbolic link using ln -s.
# Install the libaom library
apt install libaom-dev
yum install libaom-devel
# Solve the dependency problem in RHEL (CentOS)
ln -s /usr/lib64/libaom.so.0 /usr/lib64/libaom.so.3
# Solve the dependency problem in Debian
ln -s /usr/lib/x86_64-linux-gnu/libaom.so.0 /usr/lib64/libaom.so.3
Precompiled packages can be downloaded from GitHub (click to go). Please choose the mode and modify the parameters according to your actual needs in the configuration file. The explanations for each parameter are written in the comments. After modification, you can save it as a config.json file.
# Proxy mode
{
"HOST": "127.0.0.1", // Listen to the local host, use 0.0.0.0 to listen to all
"PORT": "3333", // Local port used by WebP Server
"QUALITY": "80", // Compression quality, the lower the value, the higher the compression ratio
"IMG_PATH": "https://test.webp.sh", // Proxied site
"EXHAUST_PATH": "/path/to/exhaus", // Path to save WebP cache
"ALLOWED_TYPES": ["jpg","png","jpeg","bmp","gif"], // Compressed file extensions
}
# Local mode
{
"HOST": "127.0.0.1", // Listen to the local host, use 0.0.0.0 to listen to all
"PORT": "3333", // Local port used by WebP Server
"QUALITY": "80", // Compression quality, the lower the value, the higher the compression ratio
"IMG_PATH": "/path/to/pics", // Local image path, generally set to the site's root directory
"EXHAUST_PATH": "/path/to/exhaust", // Path to save WebP cache
"ALLOWED_TYPES": ["jpg","png","jpeg","bmp","gif"], // Compressed file extensions
"ENABLE_AVIF": false // av1 compression support, not recommended for use
}
If you choose to install directly, it is recommended to use systemd to start the service. Here is an example of a one-click writing of the webp.service file. Modify the paths of the webp-server binary file and the config.json file, and paste it directly into the SSH window.
cat > /etc/systemd/system/webp.service <<EOF
[Unit]
Description=WebP Server
Documentation=https://github.com/n0vad3v/webp_server_go
After=nginx.target
[Service]
Type=simple
StandardError=journal
AmbientCapabilities=CAP_NET_BIND_SERVICE
WorkingDirectory=/[program directory]/webp-server
ExecStart=/[program directory]/webp-server/webp-server-linux-amd64 --config /[program directory]/webp-server/config.json
ExecReload=/bin/kill -HUP $MAINPID
Restart=always
RestartSec=3s
[Install]
WantedBy=multi-user.target
EOF
At this point, you can use the command service webp start|stop|status to control the operation of WebP Server. After confirming that it is correct, use systemctl enable webp to allow it to start automatically on boot.
3. NGINX Configuration#
After WebP-Server is working properly, we need to configure a reverse proxy on NGINX to hand over media files with extensions such as jpg, jpeg, gif, png, and bmp to WebP-Server for processing. Here is an example that can be added to the corresponding vhost in NGINX. It is important to note that when enabling WebP automatic return, you also need to delete the cache content of the relevant media extensions in the vhost to avoid returning WebP to unsupported devices.
%3Fvalid%3Dfalse%26imageUrl%3Dhttps%253A%252F%252Fmoe.lty.fun%252Fimages%252FJhDQ.png&w=3840&q=75)
# Forward requests for jpg, jpeg, gif, png, bmp to local port 3333
location ~* \.(?:jpg|jpeg|gif|png|bmp)$ {
proxy_pass http://127.0.0.1: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';
}
4. Supplement & Summary#
During the writing of this article, a friend reminded me that there is currently a memory leak issue with this program (click to go). The author recommends using Docker to avoid this issue by limiting memory usage. This problem occurs when WebP Server starts multiple compression processes for the same file when multiple people access a single media resource, resulting in abnormal memory usage. If you choose to install directly and for a better experience, cache preheating is a very wise choice.
# Enable 4 processes to perform cache preheating on the configured directory
./webp-server -prefetch -jobs=4 --config /[program directory]/webp-server/config.json
The author's precompiled package on GitHub only provides 64-bit x86 architecture. I feel that the author built the precompiled package on RHEL8. If you want to use it on other platforms, you can consider using Docker or compile it according to the documentation (click to go). The whole process is not complicated. After configuration, open the F12 Network tab, check the type option or check the content-type of the image. You will see that the actual image you access has been compressed into WebP. Finally, I would like to thank the author for creating such a useful tool~
Original Article Link: https://luotianyi.vc/6907.html
If you have any questions, please feel free to criticize and correct me~