Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebP – A new image format for the Web

developers.google.com

Post reply on HN
Print view View original

21–30 of 60 posts

Re: WebP – A new image format for the Web

#21

Post by billyhoffman »

Theodores wrote: post #9
workhere-io wrote: post #2

Things to consider: WebP browser support is currently terrible ( 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/ ).

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 ima…

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

Consider this: I have page.html, with an 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 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.

Re: WebP – A new image format for the Web

#22

Post by ZenoArrow »

KaiserPro wrote: post #20

this seems rather prescient: https://xkcd.com/927/

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.

Re: WebP – A new image format for the Web

#24

Post by ntakasaki »

Theodores wrote: post #9
workhere-io wrote: post #2

Things to consider: WebP browser support is currently terrible ( 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/ ).

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 ima…

>Yes, but you have saved bandwidth and your pages have loaded quickly for ~50% of your users.

I don't think ~50% of users are running Chrome. Where are you getting your numbers from?

Re: WebP – A new image format for the Web

#25

Post by yaix »

billyhoffman wrote: post #21
Theodores wrote: post #9

Earlier quoted context omitted.

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 ima…

There is a big problem with auto-converting images, and its with HTTP caching. Consider this: I have page.html, with an 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 U…

Very true.

Re: WebP – A new image format for the Web

#26

Post by drdaeman »

billyhoffman wrote: post #21
Theodores wrote: post #9

Earlier quoted context omitted.

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 ima…

There is a big problem with auto-converting images, and its with HTTP caching. Consider this: I have page.html, with an 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 U…

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.

Re: WebP – A new image format for the Web

#28

Post by scaz »

billyhoffman wrote: post #21
Theodores wrote: post #9

Earlier quoted context omitted.

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 ima…

There is a big problem with auto-converting images, and its with HTTP caching. Consider this: I have page.html, with an 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 U…

You cache negotiated responses[1] using the Vary header[2]. PageSpeed does rewrite URLs in the HTML, it just isn't needed in this case.

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13...

[2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14...

Re: WebP – A new image format for the Web

#29

Post by userbinator »

ZenoArrow wrote: post #22
KaiserPro wrote: post #20

this seems rather prescient: https://xkcd.com/927/

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 b…

> 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.

Post reply on HN