
WebP – A new image format for the Web - personjerry
https://developers.google.com/speed/webp/?csw=1
======
cromwellian
I sense another flame war. Unless there is new data from a new set of image
quality/compression tests, I would urge people to just look up the old threads
instead of rehashing the arguments again.

Note: Although YouTube announced a switch, Google+ has long been using WebP to
serve up images in the stream with substantial savings, so the usage of it by
Google on their services is not new.

------
workhere-io
Things to consider: WebP browser support is currently terrible
([http://caniuse.com/webp](http://caniuse.com/webp)), and it seems the
solution to make WebP images display in non-supported browsers is through the
help of a rather large JS file
([http://webpjs.appspot.com/](http://webpjs.appspot.com/)).

~~~
Theodores
Actually it is Google Pagespeed where the magic happens. You serve jpg, gif,
png, pcx^H^H^H and then your nginx/Apache converts them to webp for you, on
the fly, cached. If the person requesting your page runs chrome they get webp.

So that means everyone else gets a slow image format? Yes, but you have saved
bandwidth and your pages have loaded quickly for ~50% of your users.

I don't think webp is really a source image format, more something that is
browser and Pagespeed specific. Try it, you will be impressed.

~~~
billyhoffman
There is a big problem with auto-converting images, and its with HTTP caching.

Consider this: I have page.html, with an <img src=logo.jpg> tag. If I'm using
Chrome and I request logo.jpg PageSpeed/the web server detects that I support
WebP via the Accept header. It sends WebP image for the URL logo.jpg.

And that's a problem. Because the content for logo.jpg is no longer dependent
entirely on the URL. It the URL, and the values of the User-Agent or the
Accept headers, which determine the response.

This is called content negotiation and it utterly nullifies shared HTTP
caching. This is bad because shared HTTP caching can be a huge performance
win.

The right way to serve WebP images is to change the URL. The application logic
that generates the HTML should detect that browser support webp and rewrite
the image tag accordingly. In other words, page.html should include a <IMG
src=logo.webp> tag.

This means that browsers that support webp get it, browsers that only support
JPEG get it, and shared HTTP caches can be used without polluting the cache.

Sadly, PageSpeed and other technologies like it aren't currently smart enough
to re-write the URL in the base HTML page. As always, technology that
"automatically fixes problem X" rarely is the best solution.

~~~
drdaeman
Isn't the caching issue trivially fixable with "Vary: Accept" header? (No idea
whenever PageSpeed adds that or not.) Content negotiation shouldn't interfere
with caching, if both are done properly.

Also, if you respond with different HTML, you still get the caching issue,
because you may mistakenly serve cached HTML linking to WebP images to non-
capable client. So the cache should still consider Vary and Pragma headers (or
it's broken).

The only thing I don't really fancy about "/cute/kitten.jpg" serving a WebP
image is ".jpg" part. If content-type may vary, the "extension" part of the
"filename" should be generic ("/cute/kitten.image") or missing
("/cute/kitten"). That's for saving pics, when URLs transform into filenames.

~~~
billyhoffman
2 things:

First, "Vary:Accept" and Vary:User-Agent effectively nullifies shared caches.
Because instead of saving 1 copy of a response for a URL, and serving it to
all requests, a shared cache has to save 1 copy per unique combination of URL
and the Accept request header and/or the User-Agent header sent by the
browser.

Browsers send wildly different Accept header values, not only across browser
vendors but across versions as well. And the User-Agent string has insane
variation since OS, CPU, language, and more can be included.

The net result is that all these unique request header values fragment the
shared cache so much that you don't get any cache hits. The shared cache has
been nullified.

Second, if the HTML is a static file, yes you have the same problem. However,
in the modern age of web publishing, the HTML is almost always being
dynamically generated by some application logic/CMS/something. This means that
it is rarely is ever cached or marked as cachable to shared caches.

More about Vary and shared caching: [http://zoompf.com/blog/2010/03/the-big-
performance-improveme...](http://zoompf.com/blog/2010/03/the-big-performance-
improvement-in-ie9-no-one-is-talking-about)

[http://blogs.msdn.com/b/ieinternals/archive/2009/06/17/vary-...](http://blogs.msdn.com/b/ieinternals/archive/2009/06/17/vary-
header-prevents-caching-in-ie.aspx?Redirected=true)

------
crazygringo
Interestingly enough, WebP is a great format to use if you don't want users
saving your images.

More than once I've right-clicked an image to save it to disk, only later to
discover I have no program on my computer which can open or view it, except
for Chrome! No thumbnails, no previews, no Photoshop, nothing. (I know there
are plug-ins, if I really wanted to.)

------
ninthfrank07
If anyone is interested, the discussion on implementing WebP support in
Firefox has recently moved from Bugzilla
([https://bugzilla.mozilla.org/show_bug.cgi?id=856375](https://bugzilla.mozilla.org/show_bug.cgi?id=856375))
to mozilla.dev.media
([https://groups.google.com/forum/#!topic/mozilla.dev.media/qM...](https://groups.google.com/forum/#!topic/mozilla.dev.media/qMtHAyn2clI)).

~~~
ZenoArrow
Found this comment interesting... > What about a deal: if Google implements
APNG, we implement WebP ? ;)

------
danmaz74
Transparency on lossy compressed images is something that I really crave.

~~~
TazeTSchnitzel
WebP's support for animation is also great. Like animated GIFs, but in true
colour with VP8 compression _and_ optional transparency!

~~~
TD-Linux
It's not really VP8 compression, as in the full video codec. But it's neat
regardless.

------
maga
Why is this up here? Anything changed about WebP recently? Any news I might
have missed?

------
wooptoo
[http://caniuse.com/webp](http://caniuse.com/webp) Webp support in other
browsers than Chrome is virtually nonexistent. However if a big chunk of your
audience browses from Chrome, you could serve Webp today. It can be done in a
browser neutral manner by looking at the Accept header.

~~~
pornel
For IE you can serve JPEG-XR
[http://caniuse.com/jpegxr](http://caniuse.com/jpegxr) and for Safari JPEG
2000.

------
tommoor
We've been using WebP in production in our chrome-only web application for
over a year now, works well but not sure why it's on the front page of HN!

Google announcement about YouTube supporting it?

[http://www.engadget.com/2014/03/23/google-webp-youtube-
thumb...](http://www.engadget.com/2014/03/23/google-webp-youtube-thumbnails)

------
KaiserPro
this seems rather prescient:

[https://xkcd.com/927/](https://xkcd.com/927/)

~~~
ZenoArrow
How is that prescient? Standards can get replaced when something better comes
along. The question is whether WebP will be compelling enough to overtake what
came before. It looks promising at first glance.

If anyone at a browser development company is reading this, vector image
formats are more in need of disruption than raster image formats, SVG is
versatile but it's bulky, a more compact vector image format would be welcome,
especially in the age of responsive design.

That said, some technology standards can stick around far beyond what they
should. MP3 is a classic example, there are far better music formats than MP3
(you'd be hard pressed to find a worse one that's still supported), but
because of the sheer volume of music in that format, the 'good enough' status,
and the limited abilities of some of the hardware players to handle better
formats, we're stuck with it. This isn't something we should seek to
encourage, but it does happen.

~~~
userbinator
> a more compact vector image format would be welcome

SWF. It's more than just a vector image format, but it is far better than SVG
in terms of both filesize and resources required to render. Too bad for the
"Flash hater's stigma" and the direction Adobe took their player after the
acquistion... although there are now a few other alternatives including
Mozilla's Shumway.

~~~
evilduck
SWF as an image format also requires a client side runtime be installed. A
runtime with spotty cross platform performance and a poor security track
record at that. The distaste for Flash is pretty well justified, I'll take the
larger and slower SVGs over Flash any day.

~~~
userbinator
There's this:
[http://mozilla.github.io/shumway/](http://mozilla.github.io/shumway/)

Also, since Adobe removed the restrictions on creating programs to display
Flash content a few years ago, there's nothing stopping others from writing a
minimal, image-only SWF plugin.

