With modern web designs, especially those with AJAXy features, you’d be shocked to find that Javascript and CSS contribute significantly to the amount of data your browser downloads for a webpage. Usually, the Javascript and CSS files are larger than the HTML webpage itself. Continuing my trend of debunking popular or common beliefs, read on for why on-the-fly JS/CSS compression that you read about on Digg often will actually crash your site hard when you get Dugg. I also present a simple yet more efficient way of compressing your files.
On-the-Fly Compression: ARRRGGH! 
Once again, just like with WordPress pages, the most common suggestion for compressing Javascript and CSS files is on-the-fly compression. For example, see this very well-written and researched guide named “The Definitive Post on Gzipping your CSS [and JS]”. The guide outlines two methods of using the PHP code
ob_start ("ob_gzhandler");
to compress CSS (JS would work equally well) on the fly.
I discussed previously how on-the-fly compression of pages is very bad during high-load situations. Likewise, on-the-fly compression of CSS and JS is equally problematic: the constant recompression during Digg/Slashdot floods will melt weak servers, like the servers of most cheap shared hosts.
The “Definitive Post” actually considers the problem of excess CPU overhead:
Some people expressed concern about invoking PHP’s parser for this, wondering if it would either tax the server or result in no overall speed benefit… as the CSS files are cached, the file need only be processed on the first visit. As such, we have not observed this to be much of a concern.
This statement is true if your site is visited by lots of repeat visitors who cache your CSS and JS files locally. However, during the typical Digg/Slashdot flood, your site is likely to be visited by thousands upon thousands of new visitors within minutes who obviously don’t have your CSS and JS files cached. This means your server will be recompressing your CSS and JS for practically every page hit during the flood. Suppose you get 1000 new visitors within 1 minute (Wikipedia says peak traffic influx from the “Slashdot effect” ranges from hundreds to thousands of hits per minute). Also suppose you have a total of 12 CSS and JS files loaded for your page. So during this 1 minute, your server must compress 12000 CSS and JS files! Thus, on-the-fly compression is excellent for its simplicity but a bad idea if you are concerned about flash traffic and high loads.
Despite the problems, method 2 described in the “Definitive Post” that uses .htaccess without any modification or manual handling of your CSS or Javascript files is quite elegant. The following suggestion of how to compress your CSS and JS actually takes a similar approach.
JSmart Compressor: out-of-the-box minify + gzip + cache = 
My current preferred approach to compressing Javascript and CSS is to use the Ali Farhadi’s JSmart Compressor (that is, if your web server supports htaccess rewrite rules; most do). Instead of using .htaccess to run PHP gzip code on CSS and JS every time they are requested, we use .htaccess to run JSmart whenever CSS and JS files are requested. JSmart then performs basic minification on (strips whitespaces and comments) and gzip compresses the requested CSS and JS files. Most importantly, JSmart places the gzipped files into the cache directory so that they can be re-used again and again without recompression. JSmart also knows to recompress already cached CSS and JS files if the originals have been changed. In short, JSmart can compress and cache your JS and CSS without a single change to your site’s code (other than .htaccess), only performs gzip compression once per file, and it will automatically recompress and re-cache files when they are modified. Of course, JSmart also handles browsers that cannot accept gzipped content and sends them the original file.
JSmart is also very easy to setup.
- Assuming WordPress resides in your web root, simply place the JSmart files into /jsmart/.
- Look over and edit /jsmart/config.php if you like, though the default settings should work fine.
- Create and chmod 777 /jsmart/cache/.
- Make sure that .htaccess in your web root contains
RewriteEngine on
- Paste the following line into .htaccess in your web root
RewriteRule ^(.*\.((js)|(css)))$ jsmart/load.php?file=$1
- That’s it! You can verify that you are getting served gzipped CSS and JS with this web tool or the Firefox extension Live HTTP Headers, and check the cache directory.
Note that this method of compressing JS and CSS is not the most efficient. Some PHP parsing occurs per request, which increases CPU overhead compared to serving plain uncompressed JS and CSS. However, the PHP parsing is at least much less intensive than performing gzip compression every request. I believe using JSmart is a good compromise. The solution is extremely simple to implement and maintain as it requires no code modification whatsoever other than .htaccess. gzip compression is only performed once per file until the original file is changed. File size reduction is indeed significant since JSmart minifies and then gzips.
My to-do / food for thought:
The most efficient way of serving compressed Javascript and CSS is still to pre-minify (with an “offline” compressor like YUI Compressor) and pre-compress the files, save them to disk, then use .htaccess to have the web server serve them to browsers that accept gzipped content. This way, no recompression or PHP parsing is required. This method is relatively straightforward with sites where there are a small number of Javascript and CSS files, and they are located in centralized directories. However, WordPress sites usually contain a large number of CSS and JS files spread all over the place. Furthermore, you must minify and compress again any file that is modified. Seems like quite a nightmare. I do have some ideas I’m working on that can make this process more automated or at least less painful. Stay tuned.
Also, compressing JS and CSS is just part of the task. Another great performance enhancer is to combining your JS and CSS files so that the browser requests and downloads one or two files instead of a dozen when loading a webpage. Reducing the number of HTTP requests makes your webpages much more responsive. Unfortunately, this is an even more annoying problem to solve. See these posts [1, 2] for some ideas.
If you liked this post, please subscribe to my feed. Thanks for visiting!
Hi, just tried this out.
Shaved .3 of a second off my test site which was gzipping on the fly. that’s now 1.7 seconds for 81Kb (uncompressed) total download.
It took a little reworking because getallheaders() didn’t work. After a look on php builder the following solution was given:
function emu_getallheaders() {
foreach($_SERVER as $name => $value)
if(substr($name, 0, 5) == ‘HTTP_’)
$headers[str_replace(’ ‘, ‘-’, ucwords(strtolower(str_replace(’_', ‘ ‘, substr($name, 5)))))] = $value;
return $headers;
}
Which may be of use to any others trying JSmart on an unfriendly server.
An absolutely excellent article. cheers dude.
Are you going to add concatination to this project or has all development now ceased?
Hi Mike,
Thanks for your comment and helpful code snippet. I’m glad you found this post interesting. Note that I am *not* the author of JSmart (http://farhadi.ir/jsmart.html). I am merely describing methods of taking advantage of this seldom-talked-about tool.
I have worked on some code related to the automation and management of pre-compressed JS and CSS files (but not concatination, sorry). I need to find time to document, write up a post, and publish the code. Time, why is there always not enough of it?!
That’s a very interesting article. Thanks to it I’ve found JSmart a very interesting project too. Unfortunately it’s still at July 2006, nonetheless is interesting for its semplicity.
Maybe we can hack it to join the CSS and the JS togheter and to implement other ideas… let’s see!