There are 2 huge problems with this blog post.<p>First, the source image is a photograph, <i>saved as a PNG24</i> file! They then show how JPEG XR and WebP file sizes compare.<p>This is a worthless comparison. Spoiler alert: the lossless PNG24 isn't very good are storing photographic data, because its not designed to.<p>Had imgix known how to do a proper image comparison study, they would haved used a PNG24, generate a normal, non-progressive JPEG, at the "Save for web" quality setting of 70. That's you baseline. They should then generate the JPEG XR, WebP, and Progressive JPEG off the source PNG24, and compare those sizes to the size of the baseline, regular quality 70 JPEG.<p>I have seen great performance benefits from using WebP where it makes sense, and I discuss them in this video about Warby Parker [0]. But the imgix guys are going about this the wrong way to explain the benefits.<p>Second, the use of Content Negotiation is a terrible idea as well. You don't want to serve different file types from the same URL. Because then, the web server uses the Accept header, and potentially the User-Agent header, to determine the response. This means it must send a Vary: Accept or Vary:Accept, User-Agent header in this response, which renders the response essentially uncachable for shared cached. I discuss this problem here [1], but in the context of the User-Agent header.<p>Its clear the imgix is trying to help people, which is awesome. But its also clear from their advice and analysis they really don't understand what they are talking about, or can't express themselves properly. Either way, this is bad performance information, and we really don't need any more of that.<p>[0] - <a href="http://zoompf.com/blog/2013/07/how-fast-is-warby-parker" rel="nofollow">http://zoompf.com/blog/2013/07/how-fast-is-warby-parker</a><p>[1] - <a href="http://zoompf.com/blog/2012/02/lose-the-wait-http-compression" rel="nofollow">http://zoompf.com/blog/2012/02/lose-the-wait-http-compressio...</a>