It's said that a picture is worth a thousand words, but online, a picture can be worth a thousand kilobytes or more! HTTP Archive shows that images make up 64% of a Web page's total size on average. With this in mind, image optimization is key, especially when you consider that up to 40% of users will abandon a request if it doesn't load within 3 seconds. The problem with image optimization comes when designers want to keep image file sizes small without sacrificing image quality. Past attempts to create new optimized image file types better than the standard JPEG, PNG and GIF formats have been unsuccessful.
Enter WebP
WebP is an image file type that was created in 2010 and is currently being developed by Google. This image format provides lossless and lossy compression to images on the Internet.
Several big names are campaigning for the use of WebP, most notably Google, Facebook, and Ebay.
At Aristotle, we are always experimenting with techniques that improve website performance for our clients, so we ran A/B tests to understand WebP's impact on image quality and how to best implement it in our clients' projects.
A major reason we considered using WebP is the smaller file size. According to Google:
*WebP lossless image files are 26% smaller than PNGs. *
*WebP lossy images files are 25-34% smaller than JPEG images at equivalent SSIM index. *
WebP supports lossless transparency (also known as alpha channel) with just 22% more bytes.
Aristotle's tests have found pros and cons to the WebP image format:
Pros
Cons
* Smaller file size
* Weak browser support
* Different compression algorithm
* Artifacting has plastic appearance
* Smoother color gradations
* Poor exporting interface
* Alpha channel mask
Image Quality
WebP uses a new compression algorithm, so artifacting (distortion or degradation) looks different than with other file types. WebP does a nice job maintaining crisp edges in a photo but, of course, loses detail and textures as you would expect in a lossy file. Where a comparable JPEG file exhibits jittery artifacting in solid areas, WebP boasts smooth gradations down to the lowest quality settings. One downside of this is that human faces can take on a plastic or posterized appearance at lower settings.
There are a few other things to consider with the WebP image format:
Compression settings don't match up "one-to-one" with JPEGs. Don't expect a 50% quality JPEG to match a 50% quality WebP. Quality drops pretty sharply on the WebP quality scale, so it's best to start at a high quality and work your way down.
Another game-changing plus is the ability to add an alpha channel mask, much like a PNG. Unlike its lossless counterpart, however, you can often squeeze a usable WebP image to around 1/10 the size of its PNG equivalent. This is the real stand-out use for WebP, ushering in an army of options and features that would otherwise bring a website to a crawling halt with unwieldy file sizes. One real-world example compressed an 880kb PNG (24-bit with alpha channel) down to 41kb — a file savings of a 95%. While this is not the norm, it does illustrate the possibilities.
To further reduce the file size, we recommend omitting the metadata by unchecking "Save Metadata" in the dialogue. For even further compression savings, select "lossy alpha channel." Quality settings for the alpha channel mirror those of the image. For example, a 50% quality image will have a 50% quality lossy alpha channel. In our testing we expected artifacting around the masked edge, but there were also noticeable compression changes to the entire image. We certainly consider it an option to further shrink file sizes, but recommend closely monitoring the image quality when doing so. Also watch for unwelcome banding in the alpha channels with gradated fades.
We were excited to see that a Photoshop plugin-in was available for the WebP format. This allows an easy way to dial in quality settings for WebP images. The interface of the plug-in leaves something to be desired since it hasn't been fully adopted by Adobe Photoshop. At present, you cannot preview an image to assess quality settings, which is a major downside. As a workaround, you can use the Google Chrome browser for a quick comparison between files. It's also a bit awkward to access the save dialogue. To save time, we recommend setting up a keyboard shortcut to avoid repeated visits to the "Save as" drop down menu. In spite of these caveats, it's still worth the trouble.
With significant file size savings, good quality and game-changing alpha channel, WebP seems like a real contender among other image formats. While test results were optimistic, oddly there was no clear winner between formats. WebP often performed circles around the other formats, but JPEGs or 8-bit PNGs still occasionally beat WebP in size and/or quality. Be sure to do plenty of testing on your own before implementing WebP, as it may not be ideal for your needs.
Implementation
After Aristotle designers determined that WebP would be an efficient tool to use in their process, we then turned to our developers to test implementation. WebP is only natively supported in Chrome, Opera, Opera Mini, Android Browser and Chrome for Android. Firefox, IE and Safari don't have native support, although Firefox has a history with WebP. Luckily, there are a few workarounds for the lack of browser support.
Through our research we found three viable options for implementing WebP images. We wanted to make sure that we used the best option in terms of page size, keeping in mind that Speed Index is a key metric, and taking into account any Javascript polyfills needed. A polyfill is Javascript code that is implemented to provide technology that is not natively provided in a browser.
We ran four experiments to consider which direction to go.
The first test used a normal JPEG as a control, and the other three tests implemented the options listed below. We used a JPEG image and a WebP image of similar quality (269 kb JPEG and a 52 kb WebP). Here you can see the results from all four tests.
In test two, we included a 67kb WebP polyfill provided by Dominik Homberger. It allows WebP implementation on all major browsers, even IE 6 and up. This is a helpful polyfill because it doesn't require you to change the syntax of in existing code, just change .jpeg or .png to .webp and the polyfill will do the work for you.
Our next approach was to use the Picturefill polyfill to allow the use of , even if is not natively supported. This allows developers to use to use WebP if the browser supports the image format and fallback to a JPEG, PNG or other image type if WebP is not supported. (There are other amazing powers the holds, but that's not relevant to this article.)
The fourth test used code in the .htaccess of the server to implement WebP. This option was provided by Vincent Orback. Using this approach, the .htaccess code will look for a WebP version of each image on a page. If the browser supports WebP and there's a WebP image available it, will use the WebP image rather than the JPEG or PNG. This is helpful and saves considerable time since you don't have to change the syntax of in the code or the extension of your images to .webp.
After reviewing the data, we determined that the WebP polyfill (Test 2) was the smallest implementation that worked on all browsers, but we weren't impressed with the Speed Index metric for this method.
Using the WebP polyfill seemed to load visually worse than the JPEG control test and the other implementations, except on iOS.
We also noticed that on iOS devices, file sizes were 100 kb more than the other devices. It seems that on iOS 5.1, IE 8, and IE 9 the WebP image gets downloaded 3 times. While the 2 extra requests are not ideal, this is still smaller than the JPEG equivalent. We haven't tested this on updated iOS versions so there's a chance this may be resolved for iOS 6 and later. We are inclined to use this implementation initially because of the better browser support.
Looking Ahead
While the WebP polyfill is a great patch for now, we know that this implementation won't be best in the future if other browsers begin supporting WebP. Our hope is that Safari, Firefox, and IE (particularly the Spartan Browser coming in Windows 10) will embrace the WebP image format soon. Once we begin seeing a larger adoption, we will implement the method used in Test 3, using the to serve WebP images for browsers that support it and serve a JPEG or PNG file when WebP isn't supported. We plan to implement this method once Firefox begins support because the majority of visitors to our clients' websites use Chrome and Firefox.
WebP won't push JPEG or PNG out of the picture, but it is a superb tool to add to your arsenal. Get ready to welcome WebP and be prepared to do some of your own testing and comparison with each new project!
About Adrian James
Adrian James is a senior graphic designer at Aristotle Interactive. Designing award-winning work, he has produced a string of fifteen Bronze Quills, Addys and WebAwards. Adrian has crafted responsive website designs for tourism destinations such as Utah, Kentucky and Atlantic City. His knowledge of design extends to award-winning advertising campaigns and print work for a wide range of clients. A classically-trained violinist and studio musician in his spare time, Adrian is especially proud of his design work for pop culture icons Bob Marley, Elvis, Evanescence and Moby, including movie soundtrack and album covers, logos and websites.
David asked me if I'd be up for a guest post picking out some of my favorite Pens from CodePen. A daunting task! There are so many! I managed to pick a few though that have blown me away over the past few months. If you...
Regardless of your stance on pornography, it would be impossible to deny the massive impact the adult website industry has had on pushing the web forward. From pushing the browser's video limits to pushing ads through WebSocket so ad blockers don't detect them, you have...
It's best practice to provide an indicator of some sort when performing an AJAX request or processing that takes place in the background. Since the dawn of AJAX, we've been using colorful spinners and imagery as indicators. While I enjoy those images, I am...
I recently came upon an interesting jQuery article about how you can retrieve all external links within a page, build the address of the site's favorite icon, and place the favorite icon along side the link. I've chosen a different approach which...
thumbor.org provides WebP support without polyfills. If the request for an image comes with a Accepts header saying that it accepts image/webp, thumbor will send it. Otherwise it will send the format specified.
@Matt: *Excellent* article — lots of great info about your WEBP testing and a few things I didn’t know about the format — thanks for writing this. Given your research into this, I was wondering if you could help me.
A while back, I added JPEG2000 and JPEG-XR to the picturefill library you mentioned above in order to complement it’s WEBP support (it is now merged into the official version of picturefill). I have since a bit of research about these formats using it, and it’s interesting to see what I have come up with. Take a look at this example in Safari, Chrome and Firefox and IE9+, preferably on a browser 1200px wide or higher:
You can move the slider to compare the original PNG image (on the right) with the alternate image rendition (Chrome: WEBP, Safari: JPEG2000, Firefox: JPEG with an alpha channel added via SVG, IE9+: JPEG-XR). Note that although the WEBP is 221.2K, the JPEG2000 is only 126.7K! These numbers are at the 1200px breakpoint, but similar comparative numbers are true at the other breakpoints.
Furthermore, if you look closely, the WEBP rendition is not as accurate as the JPEG2000 version — I found these results quite surprising. The JPEG/SVG and JPEG-XR versions (in Firefox and IE respectively) are interesting, but the JPEG2000 one is the most impressive.
I have done other tests with truecolor alpha-channeled images, and the JPEG2000-being-smaller result seems to be consistent:
I have held off on writing a blog post on this because I was hoping I could get someone to try to replicate or successfully disprove my findings (I am using commandline tools to generate these images, and I am wondering if there are better ways to produce the WEBP images that I am unaware of).
Would you be willing to do some research with me in this area? I would love to confirm that I am not doing anything wrong here.
Kornel
Zoltan, that’s a very interesting case. The image you’re compressing has large areas of gradients of semitransparency.
WebP’s alpha channel support doesn’t take advantage of the VP8 codec, but uses a simpler palette mode, which is optimized more for GIF-like transparency. It fails quite badly on images with smooth shadows and semitransparencies. In this case it’s so bad that alpha channel takes 85% of the file!
On an opaque image you should expect JPEG and JPEG 2000 to be similar size, WebP to be 15-20% smaller, and maybe only H.265 (JS version is called BPG) to be half the size.
WebP encoder ‘cwebp’ has a lossy-lossless mode too. It’s the ‘-near_lossless’ option. It preprocesses the input before lossless compression, in order to reduce the size at the expense of some pixel modification. Alpha plane is untouched.
Thanks for the kind words! We really enjoyed writing it. We use the Photoshop plugin to create WebP images so that it’s compared in quality and size to it’s JPEG or PNG counterpart. As for your other questions I will have to refer to Adrian on this. He’s been in the game a long time and might have some insight on the situation. I encourage you to write that article though! There are always going to be people ahead of you that know more but just as many people, if not more, behind you that are waiting for you to write that article and share what you’ve learned. It’s a great thing if someone comes along and shares something else they have learned because we end of helping each other out! Would love to get in touch via twitter/email and talk about everything.
I thought WebP was a dead end? Only Google ever implemented it, and better JPG and PNG encoders (plus Zopfli, etc) came along that substantially eroded or eliminated its advantages. That’s why Mozilla decided to drop it and pretty much nobody is using it.
I’m really hoping that Firefox and Spartan will jump on board to support WebP. Either way there are a majority of users using Chrome, at least for our websites, and implementing WebP has really helped in Speed Index, page size, and overall load time.
Bernardo: I believe that’s similar to the 4th implementation test that we describe in the article using htaccess. I’m glad you like the article!
Zoltan: Thanks for the kind words! We really enjoyed writing it. We use the Photoshop plugin to create WebP images so that it’s compared in quality and size to it’s JPEG or PNG counterpart. As for your other questions I will have to refer to Adrian on this. He’s been in the game a long time and might have some insight on the situation. I encourage you to write that article though! There are always going to be people ahead of you that know more but just as many people, if not more, behind you that are waiting for you to write that article and share what you’ve learned. It’s a great thing if someone comes along and shares something else they have learned because we end of helping each other out! Would love to get in touch via twitter/email and talk about everything.
Brandon: I’m really hoping that Firefox and Spartan will jump on board to support WebP. Either way there are a majority of users using Chrome, at least for our websites, and implementing WebP has really helped in Speed Index, page size, and overall load time.
On my recently coded web applications I use ImageMagick to create the WebP and create both a JPEG/PNG (depending on origin) and WebP.
I use DOMDocument class to create most of my content, so when the browser reports that it supports WebP, I simply do a preg_replace before adding the src attribute to the DOM.
It works quite well and reduces the size considerably when serving to Chrome users, very beneficial to Chrome on Android when a wifi hotspot isn’t available, especially where cell signal is not optimal.
For ImageMagick, I use 82% quality when creating WebP. Initially I used 80% but it seems that with WebP when there are visible artifacts, they are less natural looking. 82% reduces how often I noticed this on the desktop over 80% (I never noticed them on my phone).
Ron Bates
Awesome and very informative. I was first introduced to WebP when I ran across this guide: http://www.paintshoppro.com/en/pages/webp-file/ and I was very interested in understanding it more, but your guide answered all my questions. Thank you.
I’ve retested WEBP recently and I found a lot of banding artifacts and smudging in low contrast areas making the codec completely unacceptable for anything slighter better quality than measly web-graphics even at supposedly high quality settings. For now I just use the format as a Lossless alternative to PNG. Lossy is out of question unless at least some decode-level dither filtering gets implemented to mitigate the banding problems. Really wished Google had used VP9 and maybe even 10 with Webp, VP8 is too old and inneficient. A shame BpG which is a vastly superior format is doomed to obscurity thanks to a lot of HEVC patents.
Hi, just wanted to report that this post has a bunch of images from mattschull.com that are all broken at the moment because that site has a broken SSL certificate.
You gotta check out BPG: https://xooyoozoo.github.io/yolo-octo-bugfixes/#moscow&webp=s&bpg=s
I wish this would take off, I quite like the format … more: https://news.ycombinator.com/item?id=8704629
Thanks Colin, I’ve not heard of BPG yet. I’ll check it out.
Mod_pagespeed also implements webp transparently, but it breaks with Varnish Caching.
WebP seems like the ideal filetype for optimized images for responsive web design. If only, it had appropriate native browser support…
Thanks Greg, I’ll check that out.
James I agree! I’m hoping that Firefox will come along soon and that the Spartan browser will supporting it. Time will tell.
You’re comparing lossy WebP to lossless PNG, which is completely unfair. You should use lossy PNG for the comparison: http://pngmini.com/lossypng.html or https://pngquant.org
You’re using “quality” numbers as a comparison baseline, but these are literally completely made-up metrics, and it makes benchmarks very misleading:
https://pornel.net/faircomparison
You’re quoting Google’s own performance numbers, but don’t mention independent study by Mozilla that shows difference is less dramatic:
http://people.mozilla.org/~josh/lossy_compressed_image_study_july_2014/
And you should check MozJPEG.
Do a follow-up post after you’ve checked out the BPG format. :)
We plan to!
thumbor.org provides WebP support without polyfills. If the request for an image comes with a Accepts header saying that it accepts image/webp, thumbor will send it. Otherwise it will send the format specified.
Great article anyways!
I believe that’s similar to the 4th implementation test that we describe in the article using htaccess. I’m glad you like the article!
@Matt: *Excellent* article — lots of great info about your WEBP testing and a few things I didn’t know about the format — thanks for writing this. Given your research into this, I was wondering if you could help me.
A while back, I added JPEG2000 and JPEG-XR to the picturefill library you mentioned above in order to complement it’s WEBP support (it is now merged into the official version of picturefill). I have since a bit of research about these formats using it, and it’s interesting to see what I have come up with. Take a look at this example in Safari, Chrome and Firefox and IE9+, preferably on a browser 1200px wide or higher:
Sun Xrays
You can move the slider to compare the original PNG image (on the right) with the alternate image rendition (Chrome: WEBP, Safari: JPEG2000, Firefox: JPEG with an alpha channel added via SVG, IE9+: JPEG-XR). Note that although the WEBP is 221.2K, the JPEG2000 is only 126.7K! These numbers are at the 1200px breakpoint, but similar comparative numbers are true at the other breakpoints.
Furthermore, if you look closely, the WEBP rendition is not as accurate as the JPEG2000 version — I found these results quite surprising. The JPEG/SVG and JPEG-XR versions (in Firefox and IE respectively) are interesting, but the JPEG2000 one is the most impressive.
I have done other tests with truecolor alpha-channeled images, and the JPEG2000-being-smaller result seems to be consistent:
Saturn example
Dice example
I have held off on writing a blog post on this because I was hoping I could get someone to try to replicate or successfully disprove my findings (I am using commandline tools to generate these images, and I am wondering if there are better ways to produce the WEBP images that I am unaware of).
Would you be willing to do some research with me in this area? I would love to confirm that I am not doing anything wrong here.
Zoltan, that’s a very interesting case. The image you’re compressing has large areas of gradients of semitransparency.
WebP’s alpha channel support doesn’t take advantage of the VP8 codec, but uses a simpler palette mode, which is optimized more for GIF-like transparency. It fails quite badly on images with smooth shadows and semitransparencies. In this case it’s so bad that alpha channel takes 85% of the file!
On an opaque image you should expect JPEG and JPEG 2000 to be similar size, WebP to be 15-20% smaller, and maybe only H.265 (JS version is called BPG) to be half the size.
BTW: lossy PNG at the same quality as the WebP is 465KB *(DSSIM 0.9 = 0.004423) http://i.imgur.com/5SCm39c.png
WebP encoder ‘cwebp’ has a lossy-lossless mode too. It’s the ‘-near_lossless’ option. It preprocesses the input before lossless compression, in order to reduce the size at the expense of some pixel modification. Alpha plane is untouched.
Thanks for the kind words! We really enjoyed writing it. We use the Photoshop plugin to create WebP images so that it’s compared in quality and size to it’s JPEG or PNG counterpart. As for your other questions I will have to refer to Adrian on this. He’s been in the game a long time and might have some insight on the situation. I encourage you to write that article though! There are always going to be people ahead of you that know more but just as many people, if not more, behind you that are waiting for you to write that article and share what you’ve learned. It’s a great thing if someone comes along and shares something else they have learned because we end of helping each other out! Would love to get in touch via twitter/email and talk about everything.
I thought WebP was a dead end? Only Google ever implemented it, and better JPG and PNG encoders (plus Zopfli, etc) came along that substantially eroded or eliminated its advantages. That’s why Mozilla decided to drop it and pretty much nobody is using it.
I’m really hoping that Firefox and Spartan will jump on board to support WebP. Either way there are a majority of users using Chrome, at least for our websites, and implementing WebP has really helped in Speed Index, page size, and overall load time.
Thanks for sharing Zoltan, it would be interesting to compare the webp images produced by mod_pagespeed too.
Bernardo: I believe that’s similar to the 4th implementation test that we describe in the article using htaccess. I’m glad you like the article!
Zoltan: Thanks for the kind words! We really enjoyed writing it. We use the Photoshop plugin to create WebP images so that it’s compared in quality and size to it’s JPEG or PNG counterpart. As for your other questions I will have to refer to Adrian on this. He’s been in the game a long time and might have some insight on the situation. I encourage you to write that article though! There are always going to be people ahead of you that know more but just as many people, if not more, behind you that are waiting for you to write that article and share what you’ve learned. It’s a great thing if someone comes along and shares something else they have learned because we end of helping each other out! Would love to get in touch via twitter/email and talk about everything.
Brandon: I’m really hoping that Firefox and Spartan will jump on board to support WebP. Either way there are a majority of users using Chrome, at least for our websites, and implementing WebP has really helped in Speed Index, page size, and overall load time.
Quick way how to test WebP dummy images is to use satyr.io. Docs here – http://satyr.io/documentation#type
Firefox Doesnt like that Format apparently :(
On my recently coded web applications I use ImageMagick to create the WebP and create both a JPEG/PNG (depending on origin) and WebP.
I use
DOMDocumentclass to create most of my content, so when the browser reports that it supports WebP, I simply do apreg_replacebefore adding the src attribute to the DOM.It works quite well and reduces the size considerably when serving to Chrome users, very beneficial to Chrome on Android when a wifi hotspot isn’t available, especially where cell signal is not optimal.
For ImageMagick, I use 82% quality when creating WebP. Initially I used 80% but it seems that with WebP when there are visible artifacts, they are less natural looking. 82% reduces how often I noticed this on the desktop over 80% (I never noticed them on my phone).
Awesome and very informative. I was first introduced to WebP when I ran across this guide: http://www.paintshoppro.com/en/pages/webp-file/ and I was very interested in understanding it more, but your guide answered all my questions. Thank you.
I’ve retested WEBP recently and I found a lot of banding artifacts and smudging in low contrast areas making the codec completely unacceptable for anything slighter better quality than measly web-graphics even at supposedly high quality settings. For now I just use the format as a Lossless alternative to PNG. Lossy is out of question unless at least some decode-level dither filtering gets implemented to mitigate the banding problems. Really wished Google had used VP9 and maybe even 10 with Webp, VP8 is too old and inneficient. A shame BpG which is a vastly superior format is doomed to obscurity thanks to a lot of HEVC patents.
Another very interesting alternative to webp and bpg is flif: http://flif.info/
Hi, just wanted to report that this post has a bunch of images from mattschull.com that are all broken at the moment because that site has a broken SSL certificate.