Menu Search
Jump to the content X X
Smashing Conf Barcelona 2016

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Guide To Using WebP Images Today: A Case Study

They say 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. Given this, image optimization is key, especially considering that many users will abandon a request if it doesn’t load within a few seconds.

The problem with image optimization is that we want to keep file sizes small without sacrificing quality. Past attempts to create file types that optimize images better than the standard JPEG, PNG and GIF formats have been unsuccessful.

Enter WebP Link

WebP is an image format that was created in 2010 and is currently being developed by Google. This format delivers lossless and lossy compression for images. Several big names are campaigning for WebP, most notably Google, Facebook and eBay.1

At our company, we always experiment with techniques that improve website performance. So, we ran a few A/B tests to understand WebP’s impact on image quality and how best to implement it in our clients’ projects.

A major reason why we started implementing WebP is the smaller file size. According to Google:

  • WebP lossless image files are 26% smaller than PNGs.
  • WebP lossy images files are 25% to 34% smaller than JPEG images at an equivalent structural similarity (SSIM) index.
  • WebP supports lossless transparency (also known as alpha channel), with just 22% more bytes.

Our tests have uncovered pros and cons to the WebP image format:

Pros Cons
Smaller file size Weak browser support
Improved compression algorithm Artifacting has plastic appearance
Smoother color gradations Poor exporting interface
Alpha channel mask

Image Quality Link

WebP uses a new compression algorithm, so artifacting (i.e. distortion or degradation) looks different than with other file types. WebP does a nice job of maintaining crisp edges in a photo – but, of course, it loses detail and texture, as you would expect in a lossy file. Whereas 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 low settings.

Difference in quality between JPEG and WebP2
Difference in quality between JPEG and WebP. (View large version3)
Difference in zoomed-in quality between JPEG and WebP4
Difference in zoomed-in quality between JPEG and WebP. (View large version5)

We have a few other things to consider with the WebP image format. Compression settings don’t match up one-to-one with JPEG. Don’t expect a 50%-quality JPEG to match a 50%-quality WebP. Quality drops pretty sharply on the WebP scale, so 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 one tenth the size of its PNG equivalent. This is a real standout use for WebP, allowing for a host of options and features that would otherwise bring a website to a crawl with unwieldy file sizes. One real-world example saw an 880KB PNG (24-bit with alpha channel) compressed down to 41KB – a saving of 95%. While this is not the norm, it does illustrate the possibilities.

Difference in texture quality6
Difference in texture quality. (View large version7)

To further reduce the file size, we could omit metadata by unchecking “Save Metadata” in the “Save” dialog in an image editor. For even further compression savings, we could 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 we would closely monitor the image quality when doing so. Also, watch for unwelcome banding in the alpha channels with gradated fades.

Difference in alpha channel quality8
Difference in alpha channel quality. (View large version9)

We were quite excited to discover that there is a Photoshop plugin10 for the WebP support. This makes it easy to dial in quality settings for WebP images. The interface of the plugin leaves something to be desired – it hasn’t been fully adopted by Adobe. At present, you cannot preview an image to assess quality settings, which is a downside.

WebP Photoshop plugin
WebP Photoshop plugin.

As a workaround, Google’s Chrome browser allows for a quick comparison of files. Accessing the “Save” dialog is also a bit awkward in Photoshop. To save time, we’ve set up a keyboard shortcut and hence avoid repeated visits to the “Save as” dropdown menu. In spite of these caveats, it’s still worth the trouble.

With significant file size savings, good quality and the alpha channel, WebP seems like a real contender among image formats. While test results were promising, oddly there was no clear winner between formats. WebP often ran rings around the other formats, but JPEG and 8-bit PNG still occasionally beat WebP in size or quality, or both. Be sure to do plenty of testing on your own before implementing WebP, because it might not be ideal for your needs.

Implementation Link

Once we determined that WebP would be an efficient tool to use in our process, we turned to our developers to test implementation. WebP is natively supported in Chrome, Opera, Opera Mini, the Android browser and Chrome for Android. Firefox, Internet Explorer and Safari don’t have native support, although Firefox has quite 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 supporting the WebP format. We wanted to make sure that we use the best option for page size, keeping in mind that speed index is a key metric, and taking into account any JavaScript polyfills needed.

We ran four tests to consider which direction to go in. 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 (269KB for JPEG and 52KB for WebP). The results of all four tests are available in a PDF11.

In the second test, we included WebPJS12, a 67KB polyfill developed by Dominik Homberger. It provides the WebP support for all major browsers, even in IE6 and up. The polyfill is helpful because it doesn’t require you to change the syntax of the <img> element 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 Picturefill13, a polyfill that allows the use of <picture>, even when <picture> is not natively supported. This allows developers to use <source> for WebP if the browser supports the format, and to fall back to JPEG, PNG or another image type if WebP is not supported. (Obviously the <picture> element holds other amazing powers, too.)

The fourth test used code in the .htaccess file on the server to implement WebP. This option was devised by Vincent Orback14. Using this approach, the .htaccess code looks for a WebP version of each image on the page. If the browser supports WebP and a WebP image is available, it uses the WebP image, rather than the JPEG or PNG. This is helpful and saves considerable time because you don’t have to change the syntax of the <img> element in the code or change the extension of images to .webp.

After reviewing the data, we determined that the WebP polyfill (from test two) is the most lightweight solution that works in all browsers, but we weren’t quite impressed with the speed index metric resulting when using this method. The WebP polyfill seemed to load images visually worse than the JPEG control test and the other implementations, except on iOS.

We also noticed that on iOS devices, file sizes were 100KB larger than on other devices. In our tests, we noticed that in iOS5.1 and on IE8 and 9, the WebP image gets downloaded three times. While the two extra requests are not ideal, this is still smaller than the JPEG equivalent. We haven’t tested this in updated iOS versions, so this might have been resolved. We are inclined to use this implementation initially because of the better browser support.

Looking Ahead Link

Our team has decided to implement the method used in test three, using the <picture> element to serve a WebP image for browsers that support it, and serving a JPEG or PNG when WebP isn’t supported. We believe this is the best route for progressive enhancement and still allows for a fallback image. We originally went with the implementation of the WebP polyfill but found the outcome not to be ideal.

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!

(rb, al, ml, og, jb)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
SmashingConf Barcelona 2016

Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.

↑ Back to top Tweet itShare on Facebook


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.

Matt Shull is a husband, father and Aristotle Web Producer extraordinaire. Matt is instrumental in the on-going development of Aristotle’s culture of Web Performance. He tweets and retweets tons of practical development and performance techniques via @themattshull.

  1. 1

    I love seeing others try to use webp. With the release of Microsoft Edge they now advertise in the accept header that they will… well accept jxr images (JPEG XR) haha. So using nginx and content negotiation you can now serve webp and jxr images to browsers that recognize those images.

    You only need to create those images and place them in your image directory.

    I have a test page here

    It uses work done by Ilya Grigorik and Eugene Lazutkin to add in jxr content negotiation. Fair warning though if you don’t use Photoshop to create a jxr it can be a little trying especially for new comers to the command line

  2. 2

    WebPonize is a Mac App that converts images into WebP!

  3. 3

    When was this written? Because it refers to iOS 5.1 as if it’s recent and iOS 6 as if it’s current and IE 8 and 9 as if they’re recent and refers to IE6 support as if that’s at all important in the wider market.

    • 4

      Because only had iOS 5 support at the time, that’s all we had to go off of. We used IE 8 and IE 9 because of support requirements with some of our client. It’s really more to show how far back it can be supported.

  4. 5

    There are a bunch of services that can deliver automatically transcoded images to the browsers that use them best. i.e. JPEGXR for IE, WebP for Chrome, JPG or PNG for Firefox etc. You don’t have to manually do any kind of converting – the content delivery service will automatically take your JPGs or PNGs and transcode them for each browser.

    Take a look at how automatically gives you WebP images if you’re running Chrome (also on mobile!) and JPEGXR if you’re on IE. They use a company called Instart Logic for their content delivery.

  5. 6

    Anselm Hannemann

    October 26, 2015 8:49 am

    Hm, still wonder what to do with the IMO biggest issue on WebP (and other image formats): People love to download images (just imagine how images on twitter are spread – by downloading and uploading it again). Most OS don’t support WebP and in Facebooks short test 1.5yrs ago they saw this as the biggest issue and couldn’t deal with the complaints by users about “broken images”. AFAIK there is no real solution for this at the moment? In Firefox you could add a context menu item to download the JPEG/PNG but that works in no other browser… :/ any ideas?

  6. 7

    Few months ago I published a library on GitHub ([](Responsively Lazy)) that enhances your `img` tags. You can list available image versions (the WebP ones too), and the best one will be loaded. WebP versions will be loaded only on browsers that support them.

    The library uses a nice `srcset` trick that you can learn more about at

  7. 8

    Smashing Magazine demonstrates Pros and Cons of PNG vs WEBP compression using JPG quality < 60?

  8. 9

    IMHO I think WebP is quite nice but having lack of full browser support and the need for browser-specific fallbacks respectively a further customized server configuration makes it not that interesting for me. Therefore it sounds more reasonable to me to put effort in image optimizations (like does) and stick with JPG/PNG. No fallbacks needed. For example using 8-bit PNGs instead of 24-bit PNGs will also reduce the size dramatically. Alpha masks do work in PNG too. And even SVG allows sophisticated use of JPEG and PNG alpha masks. In the end the primary problem is always the image size.

    And recently I have heard of FLIF ( which sounds quite promising regarding web images: responsive by design (partial loading of image data results in different resolutions), better compression than WebP and most other formats, animateable, patent-free & open-sourced. Sadly it is still experiental and not supported in any browser natively. So I am not sure if WebP is something to rely on for the future and if it is worth the effort. The web is fragmented enough. Time for more innovative formats like FLIF.

    • 10

      Totally agree Eyesee! Right now WebP is just a step in the right direction. We want to see more image formats come out. BPG is another example of a cool image type that has no support but looks a little promising.

      • 11

        Yes, keeping moving forward is the way to go! I am just not very sure if WebP or BPG is the right vehicle… ;)

        BPG looks nice too. But unfortunately it might be problematic because of patents (the homepage states “some of the HEVC algorithms” are protected by patents). WebP potentially also has patent issues because of the VP8 codec (obviously owned by Google, and although distributed in a royality-free manner it might not be 100% compatible to open-source software). And AFAIK the older JPEG2000 format kind of died for browsers because of patent issues. Aren’t patent issues always preventing browser adoption? Additionally I am not sure if BPG is that much superior than WebP or even JPEG (e.g. some FF people said that on why these formats are not implemented yet). Eventually the usage of BPG or WebP depends most likely on the customer/employer who is willing to pay for the extra effort and the benefit it might have. At least for me neither WebP nor BPG does ultimatively make sense for todays web image challenges. I rather spend more time in exploring SVG capabilities for raster images.

        Have you had a look on the FLIF homepage? In contrast to any other format FLIF would really address a bunch of issues with current formats. Essentially it lets the client (browser) decide how many bytes of the image should be loaded for displaying. For example this obsoletes the Facebook method of progressively showing as much as possible on as little as a few bytes loaded. Even for small screens it is just loading from a huge image as much as needed for displaying a small image. That would obsolete things like having to serve multiple versions for different screen sizes and/or resolutions. Truely responsive. Have a look at the examples section of the FLIF homepage (comparing FLIF to JPEG, PNG, GIF, BPG, WebP, JPEG2000):

        I think if switching from PNG/JPEG to another format would really be an option then a new format should solve the problems we have today with web images. From my point of view this is (primary) the image size (in terms of bytes to load and size to display) with (secondary) best possible image quality. Alpha channel is a must. Animation just nice to have. Browser support is essential so royality-free and truely open-sourced formats would be best for wide adoption (think of PNG which was created as a patent-free alternative to GIF). Effectively the way to go should be to simplifying things and not introducing more complexity. FLIF promisies to do that. In contrary WebP or BPG seems just like a small step towards innovation and these have not a clear future-proof vision for the web. At least that is what I think.

  9. 12

    WebP is an old format. It hasn’t gained traction since 2010. It’s based on a legacy VP8 codec from 2006 that was meant (but failed) to beat H.264 from 2003. All browsers support VP9 now, and WebP is the last thing keeping the outdated VP8 alive (even Microsoft implements VP9, and they’ve skipped VP8 entirely).

    The article makes WebP look better than it really is, because it ignores existence of lossy PNG and compares apples to oranges: WebP’s 10% quality is not the same as JPEG’s 10% quality – they don’t use the same scale! It’s like saying 10 miles is better than 10 kilometers. Duh! That’s why Google’s study used SSIM to normalize results to the same scale.

    WebP has file size advantage mostly at the very low end of quality range, but nobody uses low quality range in practice, because it’s a blurry mess.

    In practice WebP is only usable at quality 85+ (and only if the image doesn’t contain any sharp red edges), but when WebP is not bluntly blurring away all the textures and details, the filesize difference between WebP and JPEG becomes so small it’s not worth bothering.

    Use MozJPEG/JpegMini and tinypng, and you won’t need any complex hosting for the old WebP.

    • 13

      We’ve not had the same experience you describe in your comment. Our designers do a trade off analysis for each image we convert to WebP to make sure that little to no quality is lost and that the file size is much smaller. Sometimes it is not, which Adrian says.

      We do agree that it’s quite old, but there are still others using it such as eBay and the Washington Post.

      With the picture element it’s really not that much trouble to have a fallback image for browsers that don’t support the WebP format. Graceful degradation.

      Looking forward to better image compression in the future! Hope it sparks a real conversation about the topic.

  10. 14

    BPG is a much better format than either JPEG or WebP. See for yourselves-

  11. 17

    Hemang Rindani

    October 26, 2015 4:10 pm

    Nice article.
    Everyone loves images. They have ability to enhance user engagement. It is also easy to make an image viral over various platforms to attract visitors. Make sure to use an image that is relevant and interesting to the content. Use an optimized image that works well with different operating systems and social medias. Size is an important factor that can affect the page loading time.

  12. 18

    WebP? JPG? Really? It’s time for a format that shows the advantage of what we know about human perception! We need a format that is progressive and can show the most important details on a 56k connection already in an instant. That’s what the web and mobile experience are about, and that’s why Facebook implemented the 200byte approach. We do have most advanced techniques and algorithms at our disposal but fail to replace a quarter century old picture format? We switch OS’es 10 times faster than that. It’s a shame.

    • 19

      Much of this might be the case because the client is not in control over the quality of the content. There are only hacks that influence the client’s behaviour, but it should be the other way around (or at least be taken into account what the client requested in some way).

      • 20

        On a sidenote… Do you get the irony of using JPG images to demonstrate picture quality issues between JPG and another (slightly superior) format?

        • 21

          Please read over your first remark and next your last. So yes we all got the irony. This is (sadly) how things work on the web

          • 22

            Without irony – they say the good is the enemy of the great. That’s the missing piece in here. Once things are good enough, we’ll stick with it until we see a major progression. And the digital world doesn’t change this out of the sudden either. That means, that all efforts so far weren’t practical enough to substitute the safe haven of JPG compression with all its workarounds.

    • 23

      56k connection!? LOL, really!? Where do you live? I get faster speeds on top of Machu Picchu.

  13. 24

    Using WebP is super simple with Cloudinary – prefix your site/apps images with
    Free account –

  14. 25

    Patrick Sparks

    October 27, 2015 7:37 pm

    Adrian, Matt,

    I appreciate the effort and work that went into this. The information was very helpful, but if you are trying to show the difference between two image formats on the web – USE THE FORMATS!

    You guys used combined and compressed jpgs and pngs to demonstrate the difference between two already compressed images. I can see there is a difference, but it’s not accurate or doing a good job at actually showing how these formats perform. Let me know if I’m missing something here, but it looks like you went to the work of producing those images in the correct formats, might as well use them here as well.

  15. 26

    Great article Matt! And kind of ironic timing… KeyCDN just launched a free WP caching plugin this week that allows you to serve up WebP images and fallback to PNG/JPG. First WP plugin that allows you to do it without Javascript. I personally saw a 144% decrease in page size in Chrome vs Firefox/IE after implementing.

    • 27

      144% decrease… so it’s pushing back content from the client to the server or how should we understand? How can the site content get smaller than 100% like it was before… *scratching head*

  16. 29

    Why not just use TinyPNG (, which compresses PNG files and makes them 80%-98% smaller in file size and also has transparency support, plus doesn’t make the image lose even a little bit of its quality (check it out yourself on their website)? There’s even a TinyPNG API that let’s you compress images on the fly when they’re being uploaded to your server.

    Any specific reason why Google had to create a completely new standard from scratch (with limited browser support), while there already is a more effective, but conventional method available?

    • 30

      from the article:

      > 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 one tenth the size of its PNG equivalent. This is a real standout use for WebP, allowing for a host of options and features that would otherwise bring a website to a crawl with unwieldy file sizes. One real-world example saw an 880KB PNG (24-bit with alpha channel) compressed down to 41KB – a saving of 95%

      See for yourself. The Lenna reference image as a PNG ( using gives you a 178.6 KB sized image. The same png converted to webp at a quality of 60 gives you a 96KB image.

      In my comment below where I linked to my JXR and webp content negotiation post I have the lena reference image and file sizes. Most instances webp beats them by a lot.

      Here is my github with the reference image, and converted to webp after using MozJpeg The reference image from tiff->jpeg->mozjpeg-> to webp gives you a 17.5KB image from its original ~26kb.

  17. 31

    nice article keep it up

  18. 33

    lack in browser support

  19. 34

    I think going with the “ element is the most convincing option. The ability to fallback to a format that a browser can support feels like the right direction.

    The main problem I think is in the workflow. It will be a short time before an automated tool that can be integrated into grunt or gulp emerge and will generate the images automatically. Integrating that with CMSs is gonna be a pain.

    Thank you again for the insights, the future is nearer that what we think.

  20. 36

    I think the biggest challenge with WebP and a lot of these newer image formats is that they are dramatically too complicated for the average consumer to use. Dealing with browser compatibility, best-practices for delivery, etc.. is a big issue and not a lot of people (even professionals) are willing to go through the work to figure out how to do it correctly.

    My guess is that we’ll see the biggest adoption comping from services that abstract the actual delivery of these and make it a lot easier to use for the average person. Something like for bitmaps or or for SVG, and then the biggest adoption when companies like Squarespace start using the tech.

    I think there is a pretty big opportunity out there for people to make this stuff easier.


↑ Back to top