Tobias Baldauf (@tbaldauf) helps to keep trivago fast. He creates DevOps tools, image optimization algorithms & speaks at conferences. He's a proud dad, mindful veggy & music lover. Find out more at who.tobias.is
tl;dr: JPEG-XR, an image format supported on Internet Explorer and Microsoft Edge browser, gets software-decoded on the CPU main thread alongside Javascript and thereby negatively impacts page rendering performance and interactivity, especially in Single-Page-Apps. This measurably harms conversions.
At trivago, we multivariate-test everything. Every piece of code, every visual change and every architectural adaption is validated or rejected by its impact on user experience and KPIs. It is an exciting environment to work in! When we rolled out improved image optimizations with our trusted partner Cloudinary, we tested the impact of each image format and its compression parameters on user experience and user behavior.
Since several posts on this year’s Web Performance Advent Calendar focus on image optimization and it is now a core topic of our community, let’s add insights about JPEG-XR and its trade-offs between byte size savings and decoding performance to this discussion.
“What Happened Next May Surprise You”
JPEG-XR, an image format from Microsoft supported on Internet Explorer and Microsoft Edge and thought of as an alternative to Google’s WebP, touts several improvements over standard JPEGs, regarding color handling and compression. We tested JPEG-XR due to its promised byte size savings for our users.
We were more than a little surprised, however, when our KPIs came back negative: we were able to statistically verify a -1% negative impact on core business metrics including conversions in our test of JPEG-XRs.
Why would users react negatively to better compressed images that save bandwidth while retaining visual quality?
We halted our JPEG-XR test and switched back to standard JPEGs for Internet Explorer and Microsoft Edge. Then we discussed our findings with the smart folks at Cloudinary. During the investigation, it was suggested that Internet Explorer may have implemented the decoding of JPEG-XRs software-side on the CPU, which would utilize the same thread as the active browser tab, thereby impacting overall page loading and rendering performance. This idea offered a suitable explanation for our negative business KPIs, so we followed up on it:
For our test, we created a barebones HTML page with minimal inline CSS that showed 20 images in a grid view. The entire page and all images were served from the test machine’s disk so that no network overhead was involved. Variant A) of this barebones HTML page referenced standard JPEGs while variant B) referenced JPEG-XR encoded images. We measured the impact on the CPU core responsible for processing an up-to-date Internet Explorer 11 on Microsoft Windows 7 in user space with Microsoft Windows’ inbuilt performance monitor tool.
Graph Or It Didn’t Happen
In the graph, you can see the stress put on the CPU during page loading and rendering. The first set of peaks in the graph show the CPU stress when using standard JPEGs. The second set of peaks in the graph show the stress on the CPU when using JPEG-XR images. As you can see, the stress put on the CPU during page loading and rendering is ~2x as high when using JPEG-XRs. We can conclude that the significant increase in stress on the CPU is caused by JPEG-XR software-decoding.
While in this offline lab test the overall perceived page rendering performance did not differ much, the significant increase in stress on the CPU will impact page loading and rendering performance in real-world scenarios, especially in Javascript-heavy Single-Page-Apps.
In the first few seconds of page loading and rendering, the browser main thread often consumes 100% of its allocated CPU resources, mainly on Javascript parsing and execution. In the case of JPEG-XR, the image decode competes for CPU resources with Javascript parsing and execution as well as overall page loading and rendering because it happens software-side. Since we were able to consistently correlate JPEG-XR with a negative impact to several of our key user experience metrics, it is plausible that the image decode process is able to acquire a significant percentage of the CPU resources allocated for the browser process, thereby delaying overall Javascript parsing and execution and negatively impacting the overall user experience during page loading and rendering, which increases the percentage of bounces and degrades perceived page loading performance.
Conclusion
The processing of decoding JPEG-XRs software-side on the CPU nullifies and even outweighs the potentially positive impact of byte size savings, especially in the context of a Single-Page-Application. Let’s not use JPEG-XR on the Web. 😉