|
So following on from last weeks post
I have taken a closer look at the common tools used to compress
JavaScript. Below is a graph of the compression ratios that these tools
achieved when applied to ext-all-debug.js, the uncompressed JavaScript
from the popular ExtJS framework :
Some points to note are:
- GZip is rather different from the other forms of compression in
that it a compression of the content rather than the JavaScript, and
therefore can be applied to compressed JavaScript. I have included it
in the graph to provide an indication of the level of compression it
can provide.
- The simple compilation option was used with Google Closure as this
is typically the one that will be used. For a discussion on why, check
out the excellent post on A Log of Javascript.
- Packer is similar to GZip in that it is more a compression of the
content rather than JavaScript itself. Unlike GZip however, it has a
runtime cost associated with the unpacking of the JavaScript on each
page load.
Below is a graph of the processing time required for the above compressions:
Aside from Packer, there is not a lot of
difference, and since all of the processing is done before deployment
the compression cost does not impact the performance of the JavaScript.
The final graph below shows the compression ratios where each of the
compressed JavaScript files are then GZipped, as is more typical of
production environments.
In the final analysis it is clear that you should GZip your JavaScript, although be aware that not all browsers
correctly handle GZipped content. As to which of the other compression
tools you use, it comes down to your JavaScript. My experience showed
Packer to produce the best results for ext-all-debug.js whereas Julien found that the YUI Compressor is a better choice for jQuery. CompressorRater can help with this task although it does not yet include Google Closure.
|