Zopfli Compression Algorithm is a new zlib (gzip, deflate) compatible compressor. This compressor takes more time (~100x slower), but compresses around 5% better than zlib and better than any other zlib-compatible compressor we have found.
Being gzip compatible means that existing clients can decompress files that have been compressed with Zopfli. Specifically, web browsers will be able to understand this.
A number of people have asked what the big deal is over such a relatively small size reduction at the cost of a much slower compression process. Lets take the lastest jQuery file from the Google CDN as an example – http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js.
First I cloned the Zopfli source repo and compiled it on my Macbook Air. Took about a minute or so to clone and build. The build process only required running
Here are the results of
gzip -9 and
zopfli --i1000 on jquery.min.js:
|gzip -9||32,660 bytes||0.009s|
|zopfli –i1000||31,686 bytes||16.376s|
In this test Zopfli saved an additional 974 bytes and took over 16 seconds longer. In our Google CDN example the time it takes to do the compression doesn’t make any difference, that is something you’ll only be doing once per file. To see what the potential savings is from those extra 974 bytes we’d need to know how often the jQuery file is downloaded. I don’t know what the actual numbers are, so lets make some up. Lets say it is 1 million times per month.
So 974 bytes * 1,000,000 gives us 974,000,000 bytes per month in savings. No doubt this is a drop in the bucket when compared to total bandwidth usage at Google, but it is an improvement. The improvement wouldn’t just be for Google either, everyone who views web sites that had the Zopfli compressed jQuery would have a slightly better experience as well. Smaller file means it gets downloaded faster over my existing connection. This would be extra good for mobile users.
I think there are plenty of cases where using Zopfli to compress your files will be a nice little improvement.