1. This is exactly what I've feared and suspected about JPEG-XR, webp, and JPEG-2000 (which Safari ever so quietly supports). I especially wondered about JPEG-XR after reading how Microsoft had done some great things with GPU-based hardware acceleration for JPEG decoding in IE11: https://blogs.msdn.microsoft.com/ie/2013/09/12/using-hardwar...
I was puzzled by the fact that they never mention JPEG-XR and have never published a similar post about hardware acceleration for the more modern format. They've been incredibly lazy and unfocused on XR for years. It's effectively dead now.
2. The author of the don't use it post keeps saying it gets "software decoded". This implies that this is unusual. But it isn't. Does he think JPEGs are not software decoded? They are in Firefox, and probably every other browser but IE11 and Edge. Someone correct me if I'm wrong. Browser makers have been surprisingly inert on using GPUs for image decoding. libjpeg-turbo is used by Chrome and Firefox, and possibly Safari. It's pure CPU, albeit with some SIMD. That's "software decoding". Hardware acceleration normally means GPU, or a fixed function unit/ASIC like you see for some video codecs.
3. One percent? This was all about a -1% drop in some metric? What's the error margin?
4. He implies that there's a lot of JS in this SPA. This seems like a possible confound that won't necessarily apply to rigorous web developers who don't overload on JS (who are admittedly extremely rare in 2019). Sure, they showed that XR was using more CPU, but so do all post-JPEG formats.
5. Which leads to my last point. What about webp? He strangely never mentions it. It's like only JPEG and XR exist. webp performs very poorly in CPU efficiency compared to JPEG. What are trivago and Cloudinary seeing on that front? Is webp less taxing than XR?