Don’t use JPEG-XR on the Web

I just checked the Google homepage, and even the New Year's Eve Google Doodle currently being shown is a good ol' GIF, rather than a modern format such as WebP. And this is with me using a desktop Chrome browser that definitively supports WebP.

> Like many things, the costs of switching image formats are definite, but the benefits are questionable.

One easy way to get some of the benefits without incurring the switching costs is to leverage Cloudflare Polish[1]. I've used it at a few places, and have had good experiences. Although the majority of gains came from optimizing images that were poorly optimized to begin with, rather than the incremental improvements that occurred from enabling WebP support.

[1] https://support.cloudflare.com/hc/en-us/articles/36000060737...

However, as TFA mentions, better compression is currently a double-edged sword, because the CPU has become a bottleneck again: even top-of-the-line Android phones have weak Qualcomm CPUs, and sites use so much JavaScript that even high-end machines can struggle.

So we may end up living with JPEG for a few more years. This format has been designed when CPUs had 25Mhz, and we've had over 25 years to optimize the implementations, so we get a lot of bang for the buck from it.

Except for JPEG2000, which Safari supports but does not include in its Accepts: header. So Akamai just sniffs the user-agent and serves JPEG2000 to anything that looks like Safari, whether they support it or not.

There's a big thing that bugs me about that when it comes to the web: Software patents and licenses basically ruined wavelet-based image compression schemes on the web.

Wavelets would have been ideal. Basically, the lossy compression would work about the same as the cosine transform in JPEG, but by using the discrete wavelet transform, you basically get thumbnailing built in: Imagine transmitting a tiny little thumbnail of your image. Then, you transmit the information used to derive a version 4x that size (2x width, 2x height) from that. Then, you transmit the data used to derive the next 4x layer. Rinse, repeat -- that's exactly how image data is organized after a wavelet transform.

With some clever adaptions, this could have done away with so much cruft and complexity we have today (like image sets and @media queries for background images): Imagine just putting a 4K version of your background on the server and telling the browser how to render it (an <img> tag with a specified size, or background-size in css). The browser could then start loading the image until it realizes it has all the data for your resolution (say on your phone), and just terminate the transmission before the whole image is downloaded.

Jpeg was released the MPEG-1 ( H.261 ) era. Since then we have had H.262 / MPEG2, H.263 / Divx, H.264 /AVC, H.265 / HEVC, and the coming H.266 / VVC. If we consider the amount of improvement we got from Video Encoding, images hasn't changed much at all, we happen to fine tune the heck out of Jpeg. And I hardly call a new image format with 50% reduction bitrate compared to a nearly 30 years old tech a major breakthrough, and that is without mentioning the huge decoding resources requirement.

There are many project that just improves on JPEG, Dropbox had a lossless compressor for JPEG, and Cant remember if Pik was originally based on jpeg as well.

Unless there is a real major breakthrough that gives the current best JPG encoder quality at 25% or less its size, focusing on 200KB, 100KB, 50KB images size, ( i.e the new image will have to be 50KB, 25KB, 12.5KB ) while using within 2x decoding power. I am convinced our roadmap for Network bandwidth improvement in the next 3 - 5 years are going to make JPEG to last forever.

I'm fairly certain the article may be poorly worded. Certainly standard JPGs are decoded on the CPU side as well, are they not?

To the best of my knowledge, I don't think any browsers are doing JPG decoding in hardware; I think they use the GPU for primitives and compositing, etc.

I would look forward to being corrected if I'm wrong!

The best you can say here is that it’s within the margin of error, in which case the effect is so small it’s literally unmeasurable. In that case the null hypothesis still wins, and you should not switch.

> Is there any reason to assume that this problem is permanent and unfixable?

IE11 as tested in the article is not getting anything other than security patches. The users who use IE11 are probably also the users most affected by poor performance since they most likely have the oldest hardware.

And even if you don't, taking a 1% hit to your conversion rate and hurting user experience just because you want to use a fancy new image format is probably not a good idea.

Thinking about it, assuming they’ve got a WebP output for Chrome already this could be as simple as adding one more build step with a different encoder, and one more negotiation rule on the CDN.

It indicates to me that either the inmates are running the asylum - that devs are being given too much leeway to pursue personal interests - or (and?) that Trivago's day to day work is proving so dull that developers in some teams are inventing R&D work just to stay sane.