In an ever more mobile world, there’s a balance to be struck between the use of client and server side resources. Bandwidth is a precious resource for mobile users, as is processing power, although more because of the battery life penalty imposed by processing intensive tasks rather than any lack of processing grunt on modern smartphones.
In spite of the relative expense of bandwidth, mobile users still often expect similar levels of performance to those they have become used to on their fixed broadband connections. Site owners and online service providers, whose revenue ultimately depends on a good user experiences encouraging conversion, are also in a battle against battery and bandwidth limitations in search of technologies to lubricate the flow of data to their end users.
Services like Opera Turbo, Amazon Silk, and recent new additions to Google Chrome use the ample processing power available in data centers to reduce the bandwidth burden on mobile users while improving site response times and user experience.
Towards that end, Google’s creation and release of the Zopfli compression algorithm offers a tool that takes advantage of the relative superfluity of processing time available at the server end in order to reduce file sizes and increase download speed for web clients, albeit at the expense of increased processing time.
The Zopfli compression library, which has been released under the Apache 2.0 license, is a new implementation of the ubiquitous Deflate compression algorithm, which manages to squeeze file sized down an extra 3 – 8% compared to other implementations of Deflate like zlib.
According to Google’s Open Source Blog, the compression method is
“based on iterating entropy modeling and a shortest path search algorithm to find a low bit cost path through the graph of all possible deflate representations.”
When compared to other compression libraries, Zopfli is slower by 2 – 3 orders of magnitude. For example, a sample file of 100 MB from Wikipedia is compressed can be compressed by gzip in approximately 7 seconds, by 7-zip in 128 seconds, and by Zopfli in 454 seconds. At almost 100 times slower than gzip, it’s clear that Zopfli is not suitable for compressing dynamic content, but it is well suited for the compression of static data.
Zopfli is written in C, and is intended to be used only for compression. It is incapable of decompressing the resulting files. However, its output files can be decompressed by any of the standard decompression libraries used by web clients, including gzip. Although using Zopfli imposes a considerable extra processing cost at the server, the decompression time is equivalent to that of files compressed with gzip and zlib.