Why Mozilla’s mozjpeg project is a big deal
Earlier this month, Mozilla announced a new project,mozjpeg, whose goal is “provide a production-quality JPEG encoder that improves compression while maintaining compatibility with the vast majority of deployed decoders.” In short, Mozilla is investing in creating an JPEG encoder that will create smaller JPEGs without sacrificing visual quality. These smaller images will just work with all existing browsers because, after all, they are still regular JPEGs.
Creating an open source, backwards compatible encoding to create smaller images is a huge deal. Here’s why.
Images dominate the web.
As anyone knows, images are dominating the web. Images make up the majority of content on a webpage, both in terms on number of individual requests and in terms of bytes transferred. Historically however lossless image optimization has been only able to reduce file size by a small amount, typically 5-15%. Compared to something like HTTP compression, which can reduce non-natively compressed resources like HTML and JS by 60-80%, this may not seem like much of a benefit. However, only a small minority of web content can be optimized using HTTP compression. If Mozilla can optimize JPEGs, even by a small amount, and shear amount of images on the web means that it could have a larger cumulative effect than HTTP compression.
Introducing new technology is hard
A browser vendor launching a new open source project to create smaller photographic images on the web? Wait a second… That sounds familiar. And it should. Google is trying to do the same thing right now with WebP. Microsoft has their virtually unknown JPEG-XR. There’s even JPEG 2000. We already have several, newer, better (for various definitions of “better”) image formats we are trying to use on the web. Shouldn’t we be focused on those instead of improving JPEG?
Improving JPEG doesn’t exclude work on new formats. In fact, putting all our energy into new formats alone would be a mistake. This is because introducing a new image format on the web is an extremely hard task. In fact, it’s largely only ever been successful once: PNG. And it was not easy.
PNG was created in 1996 because of technical and legal problems with GIF. 18 years later how are we doing? GIF still accounts for 23% of all images on the web; PNG is only 28%. And while GIF’s market share is indeed propped up because it supports animation, 1 out of every 4 images on the web today are not animations. Clearly people continue to use GIF where a PNG would be better. Stoyan has written extensively on this very topic. In 18 years, with browsers and web servers and image manipulation programs that all support it, PNG has only been able to replace a little over half of all GIF images.
History shows us it takes a long time to gain traction with a new file format. But is history a good predictor of how image format adoption could happen today? After all browsers are innovating at an incredible pace and focus more on open standards than pushing proprietary, closed source technology.
While this is true, adoption is still slow. WebP about 3.5 years old. If WebP accounts for all the “other” images as measured by the HTTP archive, its adoption is only at 2%. And this isn’t a problem exclusive to image formats. SPDY is about 4.5 years old and its adoption is at ~1%. This is despite over 50% of web servers and web browsers supporting SPDY natively. On top of that, there is also more to deploying these technologies than mere software support. WebP can cause serious problems with caching due to content negotiation. Facebook experienced lots of complaints when it turned on WebP, even when the browsers, network infrastructure, and servers all functioned perfected.
JPEG isn’t going anywhere
While I am optimistic and excited about new image formats (and network protocols fopr that matter), they are clearly solutions that will take perhaps a decade or more. JPEG clearly isn’t going away anytime soon so invested resources to improve quality and reduce file size is a clear win. I will continue to watch the mozjpeg project and write more as the project continues.