WebP versus JPEG. Click the image to see the full size examples on Google’s WebP comparison page. Image: Google[/caption]
Want your website to load faster? Slim your images. According to the HTTPArchive, images account for roughly 60 percent of total page size. That means the single biggest thing most sites can do to slim down is to shrink their images.
We recently covered how you can cut down your website’s page load times using Google’s image-shrinking WebP format. Unfortunately, one of the downsides to WebP is that only Opera and Chrome support it. But that may be about to change — Firefox is reconsidering its decision to reject WebP.
The change of heart makes sense since most of the objections Firefox developers initially raised about WebP have since been addressed. However, Firefox hasn’t committed to WebP just yet. As Firefox developer Jeff Muizelaar writes on the re-opened bug report, “just to be clear, no decision on adopting WebP has been made. The only thing that has changed is that we’ve just received some more interest from large non-Google web properties which we never really had before.”
Whatever the case, if Firefox does land support for WebP it would help the fledgling format cross the line where more browsers support it than don’t, which tends to be the threshold for wider adoption.
If you’d like to experiment with WebP today, while still providing fallbacks for browsers that don’t support it, be sure to check out our earlier write-up.
WebP versus JPEG. Click the image to see the full size examples on Google’s WebP comparison page. Image: Google
Webpages are constantly getting bigger.
One way to do that is with alternate image formats like Google’s WebP, which can yield images between 25 and 34 percent smaller than more popular image formats. Despite the astounding space-saving potential of WebP it, like JPEG 2000 and other efforts before it, has not completely caught on with browsers.
So far only Google Chrome and Opera support WebP (both also automatically convert all images to WebP for their respective proxy browsing mobile services). Mozilla objected to WebP when it was first launched, but all of the issues raised in that post have been addressed as WebP has evolved. Firefox still does not support WebP. Nor does Internet Explorer.
However, as Opera’s Bruce Lawson recently pointed out, using some cutting-edge CSS wizardry you can serve WebP images to Chrome and Opera, while still offering JPGs to the rest. Here’s what the code would look like:
This code uses the new Image Fallbacks syntax, which is part of the CSS Image Values and Replaced Content Module Level 4. The format qualifier is borrowed from @font-face and ensures that browsers won’t download the WebP image if they don’t support it.
Of course this only helps with CSS background images, which probably aren’t the majority of the images most sites serve up. For content images there’s currently no easy way to do the same thing, though there might be in the future if browsers begin to support the proposed <picture> element. Because <picture>‘s syntax is roughly analogous, you would be able to do something like this:
That would cover almost all the bases: browsers that support WebP and <picture>, browsers that support <picture> but not WebP and browsers that support neither. Unfortunately it’s going to be a while before this pseudocode becomes real.
WebP has other problems worth considering before you dive in. For example, when users save an image they may have trouble getting a WebP image to open in their favorite desktop app.
Still, while WebP may have a little ways to go, the potential to significantly reduce page size appears to be winning converts. If you’d like to learn more about WebP and how you can use it, check out the video below from Google’s Making the Web Fast series.
Google built the royalty-free WebM video format with the sophisticated VP8 compression technology that it obtained in its 2009 acquisition of On2. In addition to advancing the goal of open video for the Web, the search giant also used On2 technology to build a new image format called WebP with the aim of reducing page load time by increasing the efficiency of image compression.
WebP uses some of the still-image compression techniques that VP8 relies on to compress individual video frames. The format is intended for use with lossy images as an alternative to the venerable JPEG. Google conducted a large-scale study demonstrating that WebP offers an average file size savings of 39 percent. Despite the seemingly impressive results, not everybody is convinced by Google’s findings. Mozilla, which has officially refused to support the format in Firefox, has emerged as one of WebP’s most prominent opponents.
Building mainstream support for a new media format is challenging, especially when the advantages are ambiguous. WebM was attractive to some browser vendors because its royalty-free license arguably solved a real-world problem. According to critics, the advantages of WebP are illusory and don’t offer sufficient advantages over JPEG to justify adoption of the new format.
Aside from Google—which introduced official support for WebP in Chrome 12—Opera is the only other browser that natively supports the format. Despite the ease with which it can be supported, other browser vendors are reluctant to endorse the format and make it a permanent part of the Web landscape.
After studying quality and performance characteristics of WebP, Mozilla decided last month not to support the format. The WebP feature request in Mozilla’s bug tracker was resolved with the “WONFTIX” label and a number of community-supplied patches to enable the feature in Firefox were politely rejected.
“As the WebP image format exists currently, I won’t accept a patch for it. If and when that changes, I’ll happily re-evaluate my decision!” wrote Mozilla developer Joe Drew in a Bugzilla comment.
Mozilla’s Jeff Muizelaar offered a more detailed technical explanation about the problems with WebP in a blog post. His well-articulated critique sheds light on the problems with Google’s testing methodology, lays out the weaknesses in the WebP feature set, and explains Mozilla’s broader philosophical objections against indiscriminately adding new image formats to Firefox.
Muizelaar’s complaints about Google’s WebP testing methodology are familiar because they echo some of the concerns that were raised early on by other WebP critics like x264 developer Jason Garret-Glaser. The gist of it is that Google is using peak signal-to-noise ratio (PSNR) as its basis for quality comparisons—a technical benchmark that experts say fails to account for how images are actually perceived. Another problem is that Google recompressed existing JPEG images rather than starting with uncompressed source files. Both of these factors raise doubts about the validity of Google’s testing.
WebP’s lack of basic feature parity with JPEG in areas like metadata handling and ICC color profiles is identified by Muizelaar as another major problem with Google’s format. It also doesn’t add any important features that JPEG lacks, such as support for an alpha channel. He goes as far as using the phrase “half-baked” to describe the deficient WebP feature set.
Adopting a new image format in Web browsers is a big decision. Once a format becomes a part of the Web, it will have to be supported in perpetuity—adding overhead to the browser—even if it largely fizzles and only gains a small niche following. The chances of WebP attracting widespread use at this stage are very limited, so it seems prudent to avoid shoveling it into the browser.
Muizelaar argues that there is still room for further optimization by improving JPEG compression. The time that Google is putting into WebP, he says, would be better spent by improving JPEG encoders or contributing to existing next-generation image format efforts. One in particular that he cites as more promising than WebP is Microsoft’s JPEG XR, which has a better feature set than WebP, but also suffers from a lack of obvious quality advantages.
Google’s enthusiasm for WebP hasn’t been dampened by Mozilla’s criticism. A post published on Google’s official Chromium blog last week highlights a number of quality improvements in the implementation and discusses the growing number of third-party adopters. Most significantly, Google is adding WebP support to its own Web applications—including Picasa and GMail.
A new “fancy” upsampler that Google has integrated into the decoder implementation will reduce the pixelation of edges between colors in compressed images. The encoder has been improved with an experimental feature that it can selectively apply different compression and filtering behavior to various sections of the image in ways that will reduce the kind of “ringing” artifacts that are commonly seen in lossy images. The search giant also touts improved progressive loading support for WebP, which shipped in Chrome 12.
Despite WebP’s present limitations and lack of clear competitive advantages, it seems like Google is still making meaningful progress. The WebP format isn’t ready for widespread adoption today, but further optimization and perhaps a rethinking of the container format could someday make it successful.
This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.
As part of its self-imposed mission to make the web faster, Google has rolled its own image format.
It’s called WebP, and it’s based on open source technology. Google launched the initiative Thursday night with a post on its Chromium blog.
WebP has much in common with JPEG, the most widely used of the web’s image formats. Like JPEG, the new format is intended to be used for photos on web pages, and like JPEG, the photos in a WebP image are compressed using lossy technology. The images will continue to reduce in quality the more you compress them.
But Google thinks it can squish web images down using WebP to even smaller sizes than you can get with JPEG — around 40 percent smaller, based on the company’s tests — without any noticeable loss in quality. Google has been testing WebP’s efficiency over the last few months, taking around a million images from the web (mostly JPEGs, but also some PNGs and GIFs) and running them through the new WebP compression technology.
It says its engineers have seen a 39 percent reduction in overall file size on these test images “without perceptibly compromising visual quality,” and that it expects the results to improve once development picks up. Also, you could probably get even better results if you started from an uncompressed image.
WebP is being released as a developer preview, so its not supported by any major web browsers, camera manufacturers, or the software we use to make JPEGs, like Photoshop or iPhoto. Google will no doubt quickly build it into its own browser, Google Chrome, and its Picasa photo sharing software, but it will need some major backing from every key player in the browser and digital imaging hardware and software spaces if it’s to gain any traction. So it doesn’t present much of a challenge to JPEG right now.
It may in the future, though. Images are biggest data payload on web pages — when a page is slow to load, more often than not, it’s the photos that are slowing it down. The industry as a whole has been trying to solve the page load speed issue for years, and focus has increased with the explosion of the mobile web and the growing frustration with the limits of cellular data networks.
Google has made several recent attempts to speed up web page load times, both with its own SPDY protocol for web applications and its work on WebKit and V8 engines for web browsers.
But because it’s open source, and because it’s been built on technologies proponents of the open web are already familiar with, WebP does have a chance. The first step is getting into Google Chrome, which the company says will happen very soon. After that, it’s a matter of getting support from Mozilla, Opera, Apple and Microsoft to display WebP in its browsers. Considering how willing most of those companies were to play nice with WebM video, we should expect that to happen sooner rather than later.
In the meantime, Google is also considering some tricks to speed adoption, like writing scripts that pull JPEGs off the web and re-compress them in the WebP format, then store them for later use.