Tuesday, January 31st, 2006

Ajax and CSS Optimization

Category: Editorial, Utility

The Zimbra team posted about how they compress and package their CSS and JavaScript for Ajax applications.

They show how Digg.com could change their home page to go from:

A Current Page:

Total HTTP Requests: 26
Total Size: 199246 bytes


Total HTTP Requests: 13
Total Size: 70040 bytes

What they do

First some background on Zimbra’s AJAX app and the techniques we currently use. Raw and uncompressed the Javascript alone is over 2Megs. To make our app easier to download we’ve made some optimizations.

For Javascript we combine all the files in to a single _all.js file. The order that you concat these files is important since the browser will parse the files top to bottom. The same reason why the order of the script tags in your HTML document would matter to prevent dependency problems.

We then use jsmin to remove comments, white space, and excess new lines. This gives on average 25-30% reduction in size. The final and most important step is to gzip the file. This gives on average 300-400% reduction in size. Some web applications will apply gzip compression on-the-fly, which for dynamic data is the only way. Here since the Javascript is static, which is true for most AJAX applications these days, we can pre-compress which will reduce latency and CPU overhead.

For CSS we also combine all our CSS files into a single _all.css file. This combined file is then compressed with gzip.

Now back to the experiment. I took a copy of Digg’s home page and applied the techniques above. Combined, jsminified, and gziped the Javascript, then combined and gziped the CSS. I’ve posted my resulting page. Visually and functionality nothing has changed. Under the covers however the source is quite a bit smaller. I used Web Page Analyzer to compare the results. We see a 50% reduction in the number of HTTP requests and a 65% reduction in the size of the download.

NOTE: We posted on ShrinkSafe which is a JS compression tool

Posted by Dion Almaer at 10:49 am

4 rating from 33 votes


Comments feed TrackBack URI

Maybe I’m missing something, but I don’t see a link to the article mentioned, so here it is:

Comment by anon — January 31, 2006

A better alternative than shrinksafe is : http://dean.edwards.name/packer/

It may require that you add a “;” here and there though but it optimises far better than shrinksafe. (Packer uses eval).

I also recommend using an obfuscator first.

Can anyone tell me what problems there are in Internet Explorer by serving it GZIPPED javascript and CSS files?

I tried this a few days ago, and indeed the onload thing no longer seems to work. (And this on IE SP 2!)

However I removed the onloading, and everything else works. Anyone investigated this further?

Comment by bartb — January 31, 2006

Hi bartb,

So I’m the guy that wrote ShrinkSafe and having run tests on large-scale JS compression tools, I question you statement that packer optimizes “far better than shrinksafe”. Our tests showed it to returned un-evalable code. See the comments at:



Comment by Alex Russell — January 31, 2006

I use prototype and for some reason shrinksafe produced code that didn’t work.. And as I already said, packer returned unevaluated code for me too, but as soon as I added some “;” (which shouldn’t be required) everything worked fine.

Comment by bartb — January 31, 2006

bartb: send me the file ShrinkSafe failed on. I’ll see that it gets fixed.



Comment by Alex Russell — February 1, 2006

[…] […]

Pingback by Intillium Blog » Blog Archive » Ajax and CSS Optimization — February 18, 2006

seems like a very useful app. will try to implement and see how it works

Comment by Richard — January 8, 2007

Would like to try how this works for me.

Comment by DaveG — January 9, 2007

You’re better off using JSMin for the JavaScript.


Comment by Ronan — October 16, 2007

Is there any CSS minify available?

Comment by Gbal — October 1, 2010

Leave a comment

You must be logged in to post a comment.