Your client is both right and wrong. First there was GIF, the Graphics Interchange Format, and it was pretty good for early computer systems in that it was highly compressed. Tweaks were added so it supported progressive rendering, transparent colors, etc., but the fundamental limitation was a max of 255 colors. Not so good for a photograph!

Then JPEG came along as part of the output format from the Joint Photographic Experts Group and it had all sorts of cool features including the ability to accurately render millions of colors. Much better for photos, obviously, but it was hampered by a big problem: one of the actual JPEG encoding schemes is protected under patent, so technically you need to license it to include JPEG support in your graphics application.

Enter PNG, Progressive Network Graphic. Released in the mid 1990's, it was intended to live somewhere between GIF and JPEG as a graphics format, utilizing algorithms that made it open source (by that time GIF was also under patent clouds because of its use of the patented Lempel-Ziv-Welch compression algorithm and also theoretically needed to be licensed to include in graphics software).

PNG hasn't really taken root as developers had hoped it would (though we use PNG extensively here on Ask Dave Taylor, including for 90% of our screen captures) and now Google has been analyzing the traffic on the Web and ascertained that 65% of the data and almost 25% of the traffic on the Internet are images.

WebP is Google's answer to that bottleneck, a graphics encoding and compression system that has the same capabilities as JPEG for rendering quality images, but produces files that should be 30-40% smaller.

So WebP sounds promising, there's no question: Imagine if every page you visited rendered 40% faster, or required 40% less time to download all the content. In fact, Google's researchers published a paper about the WebP format that details the following:

It's a bit tricky to understand this graph at first glance, but what you can see is that for their data sample of one million randomly chosen graphic items, the vast majority were shrunk to smaller files by utilizing the WebP graphics format (the red tics).

Google also has a gallery of JPEG images and (rendered and shown within PNG containers, a bit confusingly) their WebP equivalents, which includes the following typical example:

As you can see, there's no visible difference, but the WebP image is 31% smaller. That's quite significant, and if you multiply it by the hundreds of millions of photos in Flickr, on Facebook, and otherwise disseminated around on the Web, not to mention all the other graphical elements, a measurable savings in filesize = a faster Web for everyone. That's a good thing!

If it's adopted.

That's the Achilles heel of Web-based technologies: getting them sufficiently widely adopted in both the client and server (e.g., graphics applications) that there's a snowball's chance in heck that it can become a new standard. Google's approach is to enable WebP support in WebKit and focus on Google Chrome, but obviously, it's going to be Internet Explorer, Firefox, Safari and even mobile browsers that are going to have to include support for WebP before we'll see it deployed widely.

So, in the end, I would say that your client is right in that you need to be paying attention to WebP as a new graphics compression format - and it is pretty darn promising! - but at this point you'd be wayyyy ahead of the curve utilizing it on their site, if you could even find a graphics editor that let you save in WebP format.

As for us, we'll be paying close attention to WebP and will hope to see it sufficiently widely adopted that we can start experimenting with it as an alternative format for photographs and larger graphic images in the near future.