WebP Server Go 0.11.0 is released

We believe that open-source software is the foundation of freedom. While we’re working hard to advance our SaaS product WebP Cloud and Public Services, we’re also continually improving our open-source software versions to give users more choices.

Recently, we released a new version of WebP Server Go, which brings many new features. Due to some modifications in the configuration file format, we didn’t release version 0.10.9 on top of 0.10.8, but directly used 0.11.0.

What is WebP Server Go

WebP Server Go is an open-source program licensed under GPLv3 (at least for now), the code is hosted on https://github.com/webp-sh/webp_server_go.

It aims to optimize and compress original images to more modern formats without changing the original URL. This solves the problem of servers having additional bandwidth overhead and slow loading speeds due to the output of large old format images (such as JPG, PNG) on websites, thereby improving webpage response speed and enhancing the Pagespeed score.

Suppose you have a website: https://example.com with many pictures and photos at https://example.com/pics/someimages.jpg, ranging from 1M~5M in size. If you directly put these pictures on the webpage, it will inevitably cause the webpage to load very slowly. At this time, using WebP Server Go can:

1. Keep the original image address unchanged
2. Reduce the size of the image and output it in a more modern image format (such as webp, avif)

The advantages of WebP Server Go are:

1. There is no need to manually process all the pictures on the website in advance because it is troublesome and laborious
2. There is no need to change the image address, the image address in the URL can still end with .jpg, but the output is in webp or avif format
3. Since formats like webp and avif have browser restrictions (for example, Firefox versions 77~92 do not support the avif format), WebP Server Go will automatically output the smallest image that the browser can accept based on browser information.

How to use WebP Server Go

To give everyone a more intuitive understanding of the role of WebP Server Go, let’s take a look at a very simple use case. All my pictures are stored in the /path/to/pics directory, and I hope to have a simple HTTP service that can output optimized images after access.

At present, the simplest way is to directly use Docker container deployment. We just need to mount three directories into it. Create a docker-compose.yml file and write the following content:

version: '3'

services:
  webp:
    image: webpsh/webp-server-go
    restart: always
    volumes:
      - /path/to/pics:/opt/pics
      - ./exhaust:/opt/exhaust
      - ./metadata:/opt/metadata
    ports:
      -  127.0.0.1:3333:3333

Among them, /path/to/pics is the directory where our pictures are located. The remaining ./exhaust and ./metadata are the directories for storing optimized images and source information, respectively. For easy maintenance, they are directly placed in the same directory as docker-compose.yml.

Then start it with docker-compose up -d, and now WebP Server has started on http://127.0.0.1:3333.

Suppose our actual picture is /path/to/pics/DSC05955.jpg, then we can visit http://127.0.0.1:3333/DSC05955.jpg to see the optimized picture.

• Content-Type: image/webp indicates that the picture has been output in webp format
• X-Compression-Rate: 0.13 indicates that the current picture size is 13% of the original picture

How about it, is it easy to understand? Next, just put Nginx/Caddy and other Web Servers in front of it and it can be used externally.

More configuration/deployment information can be seen in the documentation we maintain at https://docs.webp.sh/.

New Features

Alright, let’s see what’s new in this version~

New Configuration File Format

In version 0.10.8, our complete configuration file looked like this:

{
  "HOST": "127.0.0.1",
  "PORT": "3333",
  "QUALITY": "80",
  "IMG_PATH": "./pics",
  "EXHAUST_PATH": "./exhaust",
  "IMG_MAP": {},
  "ALLOWED_TYPES": ["jpg", "png", "jpeg", "bmp", "gif", "svg", "heic", "nef", "webp"],
  "ENABLE_AVIF": false,
  "ENABLE_EXTRA_PARAMS": false,
  "READ_BUFFER_SIZE": 4096,
  "CONCURRENCY": 262144,
  "DISABLE_KEEPALIVE": false,
  "CACHE_TTL": 259200
}

The changes in this version are as follows:

• We abandoned the ENABLE_AVIF parameter and instead use the "CONVERT_TYPES": ["webp","avif","jxl"] format to define the image formats that WebP Server Go will try to convert to.

  • For example, if you want WebP Server Go to only try to convert images to avif and jxl formats, you can define it like this:

    "CONVERT_TYPES": ["avif","jxl"]
    

  Suppose your image address is http://webp.server/image.jpg, when the user accesses it, WebP Server Go will try to convert the original image into avif and jxl formats. After the conversion is complete, it will compare with the original image to find the smallest image that the browser supports and return it to the browser.

• Added a STRIP_METADATA parameter to set whether to clear the metadata of the image

The new configuration file looks like this:

{
  "HOST": "127.0.0.1",
  "PORT": "3333",
  "QUALITY": "80",
  "IMG_PATH": "./pics",
  "EXHAUST_PATH": "./exhaust",
  "IMG_MAP": {},
  "ALLOWED_TYPES": ["jpg","png","jpeg","bmp","svg","heic","nef"],
  "CONVERT_TYPES": ["webp","avif","jxl"],
  "STRIP_METADATA": true,
  "ENABLE_EXTRA_PARAMS": false,
  "READ_BUFFER_SIZE": 4096,
  "CONCURRENCY": 262144,
  "DISABLE_KEEPALIVE": false,
  "CACHE_TTL": 259200
}

Minimized Conversion

In version 0.10.8, if the user defined "ENABLE_AVIF": true to allow the image to be converted into the avif format, when the browser accessed it, WebP Server Go would simultaneously perform webp and avif conversions and wait for both conversions to be completed before outputting.

But at this time, if a browser that does not support the avif format (for example, Firefox versions 77~92) visits, it is not worth it to convert to the avif format for this. In version 0.11.0, WebP Server Go will selectively convert images after determining the formats supported by the browser, reducing response time and server pressure.

Support for JPEG XL Format

JPEG XL (JPEG Extended Range) is an image compression format designed to provide higher compression efficiency and better image quality. It is an improvement and extension of the traditional JPEG format.

JPEG XL uses modern image compression algorithms and advanced coding technologies, including features such as Variable Bit Depth and Variable Chroma. These technologies enable JPEG XL to achieve higher image quality at relatively low bit rates while reducing file size.

Picture source: https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front, as can be seen from the picture, in lossless conversion, JPEG XL is superior to AVIF/WebP format in terms of conversion speed and picture compression rate

After reading Cloudinary’s JPEG XL and the Pareto Front article (the article is good, recommended for interested readers), we decided to start experimentally supporting the JPEG XL format.

You just need to specify it in CONVERT_TYPES, for example:

"CONVERT_TYPES": ["webp","avif","jxl"]

Note: Currently, according to caniuse, only Safari 17 supports the JPEG XL format. As of the publication of this article, the libjxl version of our container runtime environment installed through the package manager is 0.7, and the latest version is 0.10.2. Upgrading to 0.10.2 can achieve an additional 20% performance improvement, and we are still solving this problem.

Support for max_height and max_width

In previous versions, we had a parameter called ENABLE_EXTRA_PARAMS, which, when enabled, could pass height and width parameters to the image for scaling and cropping.

Because this feature has a certain chance of being abused, we made it a switch for users to decide whether to turn it on.

Recently, we added max_height and max_width parameters. These two parameters are used to limit the maximum size of the image and will limit large-size images within these two dimensions while keeping small-size images unchanged.

For example, we have a 500x500px image called big.jpg. When you visit /big.jpg?max_height=200&max_width=100, since max_width is smaller, the image will be scaled to 100x100px.

If we have an 80x80px image called small.jpg, when you visit /small.jpg?max_height=200&max_width=100, since the length and width of the image are within range, this image will not be processed.

This new feature is mainly in response to the demand at: https://github.com/webp-sh/webp_server_go/issues/305.

Bugfix

In addition, we also fixed some bugs, such as:

• For the original image, it may contain EXIF information (metadata). Our output WebP/AVIF format pictures will delete these metadata by default to reduce the picture volume and minimize potential privacy leaks. However, when encountering browsers that do not support WebP/AVIF formats (such as cURL), it will directly output the original image unmodified, causing potential privacy leaks.
  • We fixed this bug
  • We provide a STRIP_METADATA parameter in the configuration file to set whether to clear the metadata of the image
• During prefetch, ALLOWED_TYPES was not used to filter the image format, which caused the program to crash during prefetch
  • We fixed this bug

We hope you will like this version. If you encounter any problems or have any new ideas, welcome to submit an Issue for feedback at Issues · webp-sh/webp_server_go!