Documentation

Improved Compression with Automatic Content Negotiation

WebP is a newer image format that provides much higher compression ratios and lower quality loss. However, it’s not fully supported in all browsers (only newer versions of Chrome and Opera, currently). About 35% of users use browsers that support WebP and therefore can enjoy much faster images.

The results are pretty amazing. On average, our customers have seen images that are about half of their equivalent file size using these formats, with no quality loss. (We discuss how we measured this at the end of this tutorial.) To make using WebP even simpler, imgix also offers Automatic Content Negotiation (auto), which will serve WebP (and other modern formats as we add them) to browsers that support them without any additional work.

Note: auto=format currently only converts images automatically to the WebP format when a Chrome browser is detected.

For a full list of image formats that imgix can output manually (including other modern formats like PJPEG and JPEG XR), see the format parameter documentation.


How Automatic Content Negotiation Works

The struggle with using these new image formats is that you have to be careful to only serve them when you know they will work and provide the most benefit. For instance, serving a WebP image to a browser that does not support it will cause the image to be blank. Creating a progressive JPEG out of a small image will increase the file size of the image without actually providing much value to the user.

Fortunately, we have already solved the headache of supporting WebP in a simple manner, with the auto=format parameter. We use the various signals available to us (including headers, user agents, and image analytics) to select the optimal image format for your user. We then serve this format to them and make sure the image is cached correctly.

Behind the scenes, these are the steps we take during content negotiation:

  1. Check if your browser supports WebP. If it does, we serve back a WebP image and return. 
  2. Check if your browser supports JPEG XR. If it does, we serve back a JPEG XR image and return.
  3. Check if the request has a fallback format. If it does, we serve back the image in the fallback format.
  4. If we hit this point, serve back the image in its original format. 

To use automatic content negotiation, simply add auto=format to your image URL:

This will cause the image referenced above to serve as a WebP image to browsers that support it and JPEG (its original format) to everyone else. imgix makes sure that the image is varied and cached properly.

For lossy images, you can still use the quality parameter (q) to control the output quality that will be returned, regardless of which format is used. For example:


Graceful Fallback with fm

By setting the format parameter (fm) in addition to the auto parameter, you can provide a fallback format. For example, WebP support alpha transparency for lossy images, whereas JPEG does not. You can choose to respond with a lossless PNG as a fallback in these cases in order to maintain alpha transparency. For example:

https://static.imgix.net/feature-retina.png?fm=png&auto=format

WebP also supports lossless implementations. Though this results in higher file sizes than its lossy counterpart, it is still often much better compressed than PNG. To ensure your images are lossless, simply add the lossless parameter like so:

https://static.imgix.net/feature-retina.png?fm=png&auto=format&lossless=1


Results and How We Measured

We’ve seen an average decrease in file size of 41% across all of our customers for images served in the newer file formats (WebP and JPEG XR). One particularly photo-heavy customer saw file size decreases of 18-74% for every image in their entire image set.

Because it was mentioned in a Hacker News thread, here’s an explanation of how we obtained our numbers. 

  1. We randomly sampled ~1% of image requests from the set of image requests from our customers who were testing content negotiation in our beta. This yielded 1,159,515 records for about a 48 hour window.

  2. We isolated and de-duplicated all requests that were returned as JPEG, or PNG. This yielded 118,037 unique image requests.

  3. We isolated and de-duplicated all requests that were returned as WebP or JPEG XR. This yielded 119,303 unique image requests. A single JPEG or PNG may be served as both WebP and JPEG XR depending on the browser support or never served as one of these formats. This is why the numbers differ from the previous bullet.

  4. We outer-joined unique original formats to unique new formats. This gave us the ability to compare the file size of JPEG or PNG against their WebP and JPEG XR equivalents. This yielded 123,791 comparisons.

  5. We then measured the comparisons to arrive at the numbers we included in this tutorial. We included statistical percentiles and average numbers.