Hacker News Reader

Comment by discreditable | Hacker News Reader

Author is going about this in completely the wrong way. The best way to determine if you should deliver webp or jpeg is to look at the browser's accept header [1]. In this header you will find a listing of what the browser is willing to accept and the order of preference.

[1] https://www.igvita.com/2013/05/01/deploying-webp-via-accept-...

View on HN

From the article:

"To emit html that references either a JPEG or a WebP depending on the browser, you need some way that the server can tell whether the browser supports WebP. Because this feature is so valuable, there is a standard way of indicating support for it: include image/webp in the Accept header. Unfortunately this doesn't quite work in practice. For example, Chrome v36 on iOS broke support for WebP images outside of data:// urls but was still sending Accept: image/webp. Similarly, Opera added image/webp to their Accept header before they supported WebP lossless. And no one indicates in their Accept whether they support animated WebP."

Well those are dumb problems but sniffing UA doesn't really fix them. You'll still have clients suddenly broken.

....what the heck is an animated WebP

     what the heck is an animated WebP

A drop in improvement for animated GIF: https://developers.google.com/speed/webp/faq#why_should_i_us...

That doesn't explain what it actually is, though. How it does multiple frames.

It does clarify that it's at least not quite WebM, but it doesn't explain how far away it is.

That's a good argument for the image host to sniff the UA string in the course of content negotiation.

It's not a good argument for crafting html that bypasses content negotiation.

The problem with solving this in content negotiation is that breaks proxy caches. If you serve uncachable html that references either jpg or webp then you can serve those resources as "Cache-Control: public", and if you include a content hash or versioning in the URL then you can send a long cache lifetime. If you use the Accept or User-Agent headers to choose what image format to send them you need to issue a Vary header, and basically all proxy caches will treat that as uncachable.

There's some progress with "Vary: Accept" support, but "Vary: User-Agent" is probably never going to be supported.

That argument's pretty weak. A bug in chrome v36 on iOS, and a limitation on the forms of webp you can serve if you want them to work in Opera, are not really good enough for me to dismiss the value of Accept headers. Why are you bothered whether the browser might or might not accept animated WebP? You're trying to send a static picture of a kitten. And likewise, Opera's lack of support for lossless? Not relevant to your use case.

Reply on news.ycombinator.com