Save bandwidth with webP – soon with fallback!

A long time ago, “responsive” didn’t mean “resize your browser window repeatedly while fellow designers orgasm until they resemble a moleskine atop a puddle”. It simply meant “Reacting quickly and positively”, meaning that the page loaded fast and you could interact with it immediately.

One way to do this is to reduce the weight of the page by serving images that have a smaller file-size, thereby consuming less bandwidth and taking less time to download a page. In the last year, web pages download approximately the same number of images, but their total size has increased from about 600K to 812K, making images about 60% of the total page size.

One way to reduce this amount is to encode images in a new(ish) format called webP. It’s developed by Google and is basically a still version of their webM video codec. Google says

WebP is a new image format that provides lossless and lossy compression for images on the web. WebP lossless images are 26% smaller in size compared to PNGs. WebP lossy images are 25-34% smaller in size compared to JPEG images at equivalent SSIM index. WebP supports lossless transparency (also known as alpha channel) with just 22% additional bytes. Transparency is also supported with lossy compression and typically provides 3x smaller file sizes compared to PNG when lossy compression is acceptable for the red/green/blue color channels.

Opera uses it precisely for this compression; it’s used in Opera Turbo, which can be enabled in Opera desktop, Opera Mobile and the Chromium-based Yandex browser. This transcodes images on-the-fly to webP before squirting them down the wire and, on slower connections, it’s still faster.

In tests, Yoav Weiss reported that “Using WebP would increase the savings to 61% of image data”.

WebP is currently supported only in Opera (Presto), Google Chrome, Yandex and Android Browser on Ice Cream Sandwich, which makes it difficult to deploy on the Web. Firefox doesn’t like it and IE hasn’t said anything (I wonder if the new confidence about technologies in the VP8 video codec on which it’s based might make them feel better about it?)

However, there’s some handy new CSS coming to the rescue soon (when browser vendors implement it). We’ve long been able to specify CSS background images using background-image: url(foo.png);, but now say hello to CSS Image Values and Replaced Content Module Level 4’s Image Fallbacks, which uses this syntax:

background-image: image("wavy.webp", "wavy.png", "wavy.gif");

(Note image rather than url before the list of images.)

The spec says “Multiple ‘image -srcs’ can be given separated by commas, in which case the function represents the first image that’s not an invalid image.”

Simply: go through the list of images and grab the first you can use. If it 404s, continue going through the list until you find one you can use. Note that this isn’t supported anywhere yet, but I hope to see it soon.

[Added after a reminder from Yoav Weiss:] It needs finessing too; Jake Archibald points out “If the browser doesn’t support webp it will still download ‘whatever.webp’ and attempt a decode before it’ll fallback to the png” and suggests adding a format() qualifier, from @font-face:

background-image: image("whatever.webp" format('webp'), "whatever.jpg");

But what about old [current] browsers?, I hear you ask. Give them the current url syntax as fallback:

background-image: url("wavy.gif");
background-image: image("wavy.webp", "wavy.png", "wavy.gif");

Now all browsers get a background image, and those that are clever enough to understand webP get smaller images. Of course, you have to make a webP version (there are webP conversion tools, including a Photoshop plugin).

It seems to me that the spec is overly restrictive, as it seems to require the browser to use the first image that it can. webP is heavily compressed so requires more CPU to decode than traditional image formats. Therefore, I could imagine a browser that knows it’s on WiFi and using battery (not plugged in) to choose not to use webP and choose a PNG/ JPG etc to save CPU cycles, even though the file-size is likely to be larger.

What about content images?

Of course, not all images on your webpages are CSS background images. Many are content images in <img> elements, which doesn’t allow fallbacks.

There is, however, an HTML5 element that deliberately allows different source files to get over the fact that browsers understand different media formats:

<video>
<source src=foo.webm type=video/webm>
<source src=foo.mp4 type=video/mp4>
... fallback content ...
</video>

Wouldn’t it be great if we could use this model for a New! Improved! <img> element? We couldn’t call it <image> as that would be too confusing and the HTML5 parser algorithm aliases <image> to <img> (thanks Alcohi). So for the sake of thought experimentation, let’s call it <picture> (or, if we’re bikeshedding, <pic> or —my favourite— <bruce>). Then we could have

<picture>
<source src=foo.webp type=image/webp>
<source src=foo.png type=image/png>
<img src=foo.png alt="insert alt text here"> <!-- fallback content -->
</picture>

And everyone gets their images, and some get them much faster.

31 Responses to “ Save bandwidth with webP – soon with fallback! ”

Comment by Paddy O'Reilly

Funnily enough I’ve been experimenting with WebP for the past few days.
The only reliable way to use it is, your favourite, server side detection.

Comment by Goatpants

I’m skeptical about polluting the web with a non-standard format. Those images don’t work when shared with others, saved to disk, etc.

Have you tried JPEGmini and TinyPNG? They produce files as small as WebP, but are compatible with everything, no hacks.

Comment by Jake Archibald

Goatpants: I haven’t been able to beat webp’s compression with JPEGmini or TinyPNG. Is there an example you can point to?

Comment by Jon Hicks

“…resize your browser window repeatedly to make a website reformat while your fellow designers orgasm themselves into a moleskine atop a puddle”

I hope you can me repeat this back to you, in a whiney childish voice! ;)

Comment by Alohci

Great article Bruce. Totally agree about the picture element. One minor point – “some older browsers alias to ” – Not just older browsers. The alias is written into the HTML5 parser algorithm. (Tree Construction – In body insertion mode – A start tag whose tag name is “image”)

Comment by Charlie

Note: a common mistake when citing httparchive statistics is to fail to take changes in the sampling base into account. There has been a significant expansion of the base over the last 12 months and the default comparison is, therefore, flawed. Only like-for-like comparisons such as the “Top 1000″ are useful in this respect. This still shows a rise but a less dramatic one.

That said, WebP rocks as a format. It has both signifcantly better compression numbers and quality when compared with JPEG no matter what additional tweaks are employed. The easiest way to use it is to enable the filter in mod_pagespeed, no changes to HTML required, no new tags.

Comment by Peter Keating

[...] us to specify multiple images and the browser will load the appropriate image for the browser. Bruce Lawson has written an article detailing how that would [...]

Comment by Facebook tries Google's WebP image format; users squawk | LNW

[...] Another fan of WebP is CDN Connect, a content delivery network company that hopes to get ahead by easing Web developers’ image-support pains. Founder Adam Bradley said he’d like to see a particular browser change: a change to information called the HTTP accept header that the browser sends to a server. With the change, browsers could tell servers they can handle WebP, and servers could start delivering those images immediately without workarounds. [...]

Comment by Facebook tries Google's WebP image format; users squawk - Talk Tech

[...] Another fan of WebP is CDN Connect, a content delivery network company that hopes to get ahead by easing Web developers’ image-support pains. Founder Adam Bradley said he’d like to see a particular browser change: a change to information called the HTTP accept header that the browser sends to a server. With the change, browsers could tell servers they can handle WebP, and servers could start delivering those images immediately without workarounds. [...]

Comment by sam

hmm

we kill all the advantages and saved bandwidth in modern browsers.

background-image: url(“wavy.gif”);
background-image: image(“wavy.webp”, “wavy.png”, “wavy.gif”);

the browser will download the gif file and if the browser is modern enough to understand image (); then the browser will additionally download the webp or png too. so modern browsers will stress the wire a bit more.

Comment by qc

Is the space saving really worth the cost of compatibility outside the browser? WebP isn’t usable at all outside the browser. At what point are the space savings weighed against all other relevant factors?

Comment by qc

@Charlie

The compression is good on WebP, but the quality of JPG (at the coat of size, of course) is still much better in all of my testing. WebP looks like a middle quality compressed JPG, great for simple images and smaller ones, not great when detail is needed, IMO.

Comment by Dave

The smaller filesize of Webp should save battery overall even if it takes more CPU effort to decode.

There’s already some data out there about the “time to glass” speed of display between webp and jpeg where the extra decode time is dwarfed by the reduced download time. Since power efficiency is based on “the race to idle”, you want to get stuff done fast even if you work a bit harder to get it done quicker and return to deep sleep where you get real the power benefits. This goes double if your workload involves having the WiFi radio on too.

Comment by Sander

Oddly, the article you quote regarding Firefox is from April 2011, released just after Firefox 4 was released. FF4 and up support WebP in <video> element (see caniuse.com), so this might get better in the future.

Comment by Kevin L.

You can use WebP pretty much just fine with merely this fallback happily provided by the creator of webP

http://webpjs.appspot.com/

I’ve been able to use webP on my iPhone4s, a 2010 iPod Touch, IE9, IE10, and Firefox just fine.

If you want to be REALLY careful, I suppose you can
just have a .jpg defined first with the use of picturefill along ithin a tag and have a media query that covers all sizes that the webP format always replaces

That way, that the very least, people have a .jpg to reasonably see if they disable JavaScript, or for some weird reason their JavaScript is handled in a weird way that can perhaps happen with Opera Mini.

Considering that some browsers such as Firefox I believe are removing the ability to disable JavaScript at all (and let’s face it, with things like Angular.js, Ember.js, Rails 4 Turbolinks, Backbone.js, and so on, if someone disables JavaScript forcibly, they’re more than likely aware of what problems that’ll bring to their web experiences throughout the web; even Opera Mini doesn’t necessarily disable JavaScript it serves it server side in a way that has a few hiccups here and there. ), it’s becoming a moot point.

Just like the usage of CSS Animations where 3/4 of users have access to it, let’s move the web forward now.

Comment by Kevin L.

Update: It even supports all the way down to IE6; as far as I’m concerned, this problem is over.

If it wasn’t for the fact it’s could be outside the control of the user in some draconian environment, those with JavaScript disabled should have a pop-up telling them to enable their JavaScript; if they don’t like it tell them to eat your shorts, you’re saving them money…