WebP, JPEG XR, & Progressive JPG Support w/ Auto Content Negotiation
Today, we are announcing support for several new web image formats. These formats allow you to serve your images more efficiently while maintaining high levels of quality. The formats are WebP, JPEG XR, and progressive JPEG. At the same time, we are also announcing automatic content negotiation. Automatic content negotiation makes it incredibly easy to serve these new image formats to the right browsers without any additional work.
WebP and JPEG XR are newer image formats that provide much higher compression ratios and lower quality loss. However, they are not fully supported in all browsers. WebP is supported in newer versions of Chrome and Opera. JPEG XR is supported in newer versions of Internet Explorer. About 60% of users use browsers that support either of these two formats 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! The same quality image, half of the size. (We discuss how we measured this at the end of this post.)
You can begin using these formats right now with the addition the new values “webp” and “jxr” to the format parameter (fm). For example:
http://static.imgix.net/treefrog.jpg?fm=webp (Returns a WebP image)
http://static.imgix.net/treefrog.jpg?fm=jxr (Returns a JPEG XR image)
Progressive JPEGs restructure your image so that a low-resolution version of your image loads first, followed by progressively higher resolution versions of the image. While this does not necessarily accelerate the transfer of the image, it does give faster visual feedback to your user. Your user sees a blurry image load very fast before improving to the full quality image. This is instead of having the full quality image just pop in after a long pause. Giving visual feedback quickly is especially useful for larger images in slow connection environments (e.g. roaming mobile phones).
By default, if an image is being served as a JPEG and the total number of output pixels is more than 22,500 (~10kb in JPEG compressed image data), we will return a progressive JPEG automatically. Otherwise, the increased image weight of supporting a progressive JPEG is not worth it and we deliver a regular JPEG instead.
You can force the use of progressive JPEGs by setting the new value “pjpg” as the format parameter (fm). For example:
http://static.imgix.net/treefrog.jpg?fm=pjpg (Returns a progressive JPEG image)
Automatic Content Negotiation
The struggle with using these new image formats is that you have to be careful to only serve them in the situations where 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 not show up. Or, 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 these formats in a simple manner. It is called automatic content negotiation. What this effectively means is that 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 back and make sure the image is cached correctly.
Behind the scenes, these are the following steps that we take during content negotiation:
Check if your browser supports WebP. If it does, we serve back a WebP image and return.
Check if your browser supports JPEG XR. If it does, we serve back a JPEG XR image and return.
Check if the request has a fallback format. If it does, we serve back the image in the fallback format.
If we hit this point, serve back the image in its original format.
To use automatic content negotiation, simply set the “auto” parameter to “format”, like so:
http://static.imgix.net/treefrog.jpg?auto=format
This will cause the image referenced above to serve as a WebP image to browsers that support it, a JPEG XR image to browsers that support it, and JPEG 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:
http://static.imgix.net/treefrog.jpg?auto=format&q=65
By setting the format parameter (fm) in addition to the auto parameter, you can provide a fallback format. So for example, WebP and JPEG XR support alpha transparency for lossy images whereas JPEG does not. You can choose to respond with a lossless PNG as fallback in these cases in order to maintain alpha transparency. For example:
http://static.imgix.net/feature-retina.png?fm=png&auto=format
WebP and JPEG XR also support lossless implementations. Though they incur higher file sizes than their lossy counterparts, they are often much better compressed than PNG. To ensure your images are lossless, simply add the lossless parameter like so:
http://static.imgix.net/feature-retina.png?fm=png&auto=format&lossless=1
A handful of our customers have been field testing these features for us and the results are incredible. We have seen an average decrease in file size of 41% across all of our customers for images served in these new formats. One of our particularly photo heavy customers saw image file size decreases of 18-74% for every image in their entire image set when serving out these new file formats!
We could not be more excited to be rolling out these advanced image formats to our customers. Everything we have just described is available for you to use in production right now. Sign up at https://webapp.imgix.com/signup to start using these image formats today!
UPDATE: As it was brought up in a Hacker News thread, we wanted to explain 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 deduplicated all requests that were returned as JPEG, or PNG. This yielded 118,037 unique image requests.
3.) We isolated and deduplicated 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 blog post. We included statistical percentiles and average numbers in the blog post.
