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

31–40 of 60 posts

Re: WebP – A new image format for the Web

#31

Post by ZenoArrow »

userbinator wrote: post #29
ZenoArrow wrote: post #22

Earlier quoted context omitted.

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.

Can you give a size comparison between SWF and SVG (e.g. file size of same image in both formats)?

Something along the lines of HVIF could be a good fit for the web (perhaps less limitations on image ratios): http://en.wikipedia.org/wiki/Haiku_Vector_Icon_Format

Re: WebP – A new image format for the Web

#32

Post by ZenoArrow »

ninthfrank07 wrote: post #4

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 ) to mozilla.dev.media ( https://groups.google.com/forum/#!topic/mozilla.dev.media/qM... ).

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

Re: WebP – A new image format for the Web

#33

Post by billyhoffman »

drdaeman wrote: post #26
billyhoffman wrote: post #21

Earlier quoted context omitted.

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

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://blogs.msdn.com/b/ieinternals/archive/2009/06/17/vary-...

Re: WebP – A new image format for the Web

#34

Post by jfoster »

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…

Why does the absolute filesize of SVG matter? Nearly all web servers will compress it before putting it on the wire.

Re: WebP – A new image format for the Web

#35

Post by threeseed »

buzzkills wrote: post #16
threeseed wrote: post #12

Earlier quoted context omitted.

WebP was released 3 years ago hence your entire premise is faulty. The real truth is that being the best technically rarely guarantees success in the market.

It took longer than that for png to stick.

You missed my point. Technology is not the reason WebP is probably going nowhere.

Apple, Microsoft and Firefox for whatever reason (politics/principle) either won't support defacto standards or have to be dragged kicking and screaming into doing so (see SPDY). And without those three you are never going to get above 45%.

Re: WebP – A new image format for the Web

#36

Post by jessaustin »

ntakasaki wrote: post #24
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…

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

Perhaps 50% of your users aren't, but services exist for which that is the case. It doesn't really change the point being made however: would you really have preferred the statement "...your pages have loaded quickly for 38.271% of your users"? That's why the "~" was included to indicate approximation.

Re: WebP – A new image format for the Web

#37

Post by justincormack »

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…

That does not solve the problem either, than you cannot cache the served page, as it will either have logo.webp or logo.jpg in it (well if it is dynamically generated per user this might not be an issue).

The correct answer is something like the video tag, with a choice, polyfills, or headers that are useful enough to do a small scale Vary on. None of which are very good solutions.

Re: WebP – A new image format for the Web

#38

Post by [deleted] »

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…

[deleted]

Re: WebP – A new image format for the Web

#39

Post by acdha »

drdaeman wrote: post #26
billyhoffman wrote: post #21

Earlier quoted context omitted.

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

> Content negotiation shouldn't interfere with caching, if both are done properly.

Unfortunately, “done properly” excludes things like nginx's cache module, a number of CDNs, and even certain browser caches. Some of the bugs are obvious – e.g. returning gzipped data to a client which didn't request it – but others will simply require monitoring to realize that your cache isn't caching anything or has a dismal cache hit rate because every permutation of request headers and the values referenced in Vary are being treated independently. Worse, all of these can change unexpectedly due to updates in “stable” software so you need deep monitoring checks to ensure that everything is still working the way it was when you set it up.

The more I've used content negotiation, the less I'm convinced that it's a desirable feature. Unless you tightly control the client, server and all intermediaries you'll spend a ton of time on operational overhead and the alternative is that you simply use unique URLs which will always work correctly after the initial implementation, which is also easier.

Re: WebP – A new image format for the Web

#40

Post by ZenoArrow »

jfoster wrote: post #34
ZenoArrow wrote: post #22

Earlier quoted context omitted.

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…

Why does the absolute filesize of SVG matter? Nearly all web servers will compress it before putting it on the wire.

It's not just the filesize, it's also the rendering speed. I'm not saying SVG is terrible, I'm just pointing out there's probably room for a smaller vector format that's more focused on the needs of modern websites.
Post reply on HN