Summary: mozjpeg slightly better than libjpeg-turbo but slower to compress.

cloudflare assigned an engineer to optimize the library for speed and they plan to contribute the optimizations back.

I don't understand the point of this type of comment. It's a summary of something short (that didn't need a summary) and it misses critical information.

A lot of people (myself included) read the comments first, and then visit the article if our interest is piqued. That's why comments like the GP get upvotes.

what jewel said. I always read comments first.

It doesn't really need a "summary" though. Maybe you could add something to the conversation? Like "Oh, I didn't know libturbo was that slow" or "I'm glad Cloudflare is contributing back to the project."

It doensn't "need" a summary. But it's nice for those of us who check comments before bothering with the actual article.

TL;DR

They're sticking to lossless optimizations, so they're only benefiting from the "jpegcrush" part of mozjpeg that chooses separation of progressive scans for best compression.

The difference would be bigger if they used mozjpeg for lossy (re)compression as well, as then they'd also get trellis quantization.

Polish also does lossy compression if the user selects it. This blog post looked at mozjpeg performance in the 'lossless' case.

I don't think that fact that you're only looking at lossless compression is clear enough in the post. People see "JPEG" and "compression" and they assume you're talking about lossy compression. The post doesn't include the word "lossless" to describe what you're doing, people have to figure it out.

Happy to hear you're seeing benefits from mozjpeg, and I look forward to the results of your work optimizing run-time performance. Thanks for giving mozjpeg a shot, publishing your results, and contributing back!

The last paragraph mentions that Cloudflare uses LuaJIT (and C++ Aho-Corasick).

Cloudflare uses the OpenResty web server (Nginx+LuaJIT), that's quite interesting: http://blog.cloudflare.com/pushing-nginx-to-its-limit-with-l.... OpenResty is one of the top performing web servers in this well known benchmark: http://www.techempower.com/benchmarks/ , http://openresty.org/

The zlib fork with "massive performance improvements" appears to perform worse than the earlier and actively developed zlib performance patch set from Intel [1]. Why start from scratch?

[1] https://github.com/jtkukunas/zlib

I noticed they had a zlib fork as well. The Zlib team (mark adler?) hasn't merged in the intel patches as far as I know. Maybe someone needs to make some kind of official fork of zlib, development on it seems to be stalled.

Mozjpeg's gain come partly from using progressive JPEG encoding, which is also available in libjpeg-turbo. See the post http://www.libjpeg-turbo.org/About/Mozjpeg from libjpeg-turbo's author. And actually, the photo_3.jpg picture in the blog-post is progressive jpeg. So the command line for a fair comparison should probably be: jpegtran -outfile out.jpg -optimise -copy none -progressive in.jpg

Thanks for pointing this out. I went back in and checked and I was using the -progressive option on the jpegtran command and so the comparison was done with -progressive.

However, when I generated the image in the blog post I didn't do that and so I have rerun it. Updating the blog post now.

oh, ok. Thanks for the update!

I've done some limited tests myself, and I'm not convinced by mozjpeg (yet). While savings can be quite significant, up to 10% for large images, there is definitely quality loss, albeit minor. Trellis seems to lay a faint blurriness over the whole image. I admit it's difficult to notice at 1:1 resolution and objectively a good trade, but I'm still wary and will wait for further improvements.

So switch to mozjpeg 2.0? You only need to compress once. You have to serve the file many times, and it reduces storage space.

Yes, but we'd pay the price of higher CPU.

If by 'we' you mean the users, I don't think it makes any difference to the decoding process.

'we' in this case means cloudflare, where jgc is employed

I am very curious about the zlib improvements. I would like to see more details about that.