JPEG was an enormous improvement, particularly given the far slower connections in use at the time: waiting minutes rather than hours to download an image over my 2400bps modem was huge. In contrast, WebP offers marginal compression improvements, significantly increased hardware requirements and only a few technical improvements (e.g. alpha channels & lossless, although since the latter is so much slower and less effective than PNG I'm not sure there's much of a point).

For many users, this simply isn't enough to justify pushing it through the toolchain.

It may be slower but why do you think its less effective?

http://extrememoderate.wordpress.com/2011/11/28/a-web-centri...

And that's not counting the benefits of when PNG is used for alpha in otherwise photorealistic images where you can get 70% benefits at web sizes.

Less effective = lower compression savings. I was testing with source lossless JP2s in the 6MB range: PNG was 14MB and WebP took at least 10x compression time to hit 20MB (tied with TIFF LZW for least savings).

So it looks like it is effective in web use cases, like lossy photos (especially with alpha), logos, icons etc., but not for non-web cases like large, lossless photos that need to be compressed quickly. Seems like a good engineering tradeoff to me.

First, declaring everything WebP is bad at as "non web" assumes that everyone uses the web only for things they don't care about, which isn't remotely true as the original article shows. People save what they can see - and normal people don't want to switch tools for each situation.

Second, it's still not the case that WebP offers a significant advantage over JPEG-2000 or JPEG-XR, both of which are standardized, better supported, more flexible, and have much better designed file formats.

But JPG was like 10x better than the other image formats available at that time for photographs. WebP hardly delivers 1.2x improvement... This is virtually unnoticeable.