I've done a search for this but haven't seen it posted yet so I thought I'd share this performance tip.

I'm currently working on quite a large site with a lot of stuff going on in the front end - lightwindows, funky effects using moo and prototype, content related style sheets loaded from a bespoke cms, video overlays...all sorts of stuff.

To make all this trickery work pages had a lot of separate css and javascript files to load, which got me thinking about performance issues.

One problem is that when you start piling additional libraries and include files into a page it ups the number of http requests that you need to make on the server, which in turn slows down the page load time considerably.

One common performance tuning tip is to cut comments and whitespace out of your css and .js files and combine as many of them as possible to reduce the number of http requests. This is all well and good but it makes your scripts in particular a pig to maintain.

Anyway in searching around for a solution I came across a script called combine.php, which automatically combines your files, compresses them and caches them for later use.

The performance gains I've noticed are pretty remarkable on complex pages, but on the downside if you like to "code" visually (e.g. Dreamweaver "Designer" mode) your wysiwyg editor won't know what to do with your pages and will display them unstyled. Not really an issue for me but it's forcing my web designer colleague to learn some good hand coding practices

Anyway, more info from the authors blog here:
http://rakaz.nl/item/make_your_pages..._and_css_files

Hopefully some will find this useful.

Sounds interesting will have a look.

Why HTTP requests? I can see how they'd play a role in performance, but not the most important role. If you take 5 js files and copy them all into 1, it's the same number of bytes, just in a different arangement. I agree taking the whitespace out will make a big difference (specially with indentation) but if you change things periodically, you might be better off letting the browser cache everything but the one file you changed?

I don't know PHP so I'm just thinking out loud in general.

im not sure if the combine.php script does this i only had a quick look i will look in much more detail tomorrow. but i think it kind of shoves ALL your external files css and JS into one file, removes all the crap automatically and compresses it so the browser gets a smaller file but the "real" file remains readable and editable, and the script also creates a cache of the file and from the quick look seems to check if the file(s) have been update if so it updates the cahce if not it just uses cahce which has already been processed so its doesnt have to work...

I think im right. as i said have to look at it in detail tomorrow.

Night night all.
DAN!

If you take 5 js files and copy them all into 1, it's the same number of bytes, just in a different arangement.

Not exactly...
I did not spot a pattern, but the successive files are not downloaded at the same time. It looks like the browser have a limited concurrent connections pool, and will delay some file loading.
Take a look at the loading elements on this site main page:
http://tools.pingdom.com/fpt/default...pe=0&save=true

Typically, you have the index page that is loaded first, and then a series of images and ressources.
Tunelling them through 1 connection on like the combine.php makes reduces the number of connections made to the server, and spare a little time in the page loading, removing content negotiation from the requests and the limitation on the connection pool.

Seeing how a web server like apache is designed, in it's default configuration mode (with threads spawning for each connections) and taking in account that if modules are compiled in the server, each threads can grow a substantial size in memory (I've read report up to 80Mo per threads for apache with PHP as a module, but don't remember the details upon the shared usage of the threads).

Limiting the number of concurrent connections can help to limit the impact on the server load, on a high traffic and media intensive site.

You know guys, performance slowdown of using 5 separate files with whitespaces instead of single one with whitespaces removed is NOTHING compared to slowdown of using mysql queries with incorrect joins and not using indexes. You should optimize static files after and only after all your scripts are running perfectly and are as fast as they could be. If your script takes 5 seconds and 20Mb memory to generate the page it is quite stupid to talk about performance optimization by removing whitespaces from css file.

Considering further optimization of sending static files you will have to use some lightweight http server instead of apache to send static, while apache only should serve dynamic pages.

mtishetsky is right on target. If you want to see huge performance gains, setup "lighty" or lighthttpd to serve up your static content. You'll see excellent performance gains from this if you have that sort of control over your server.

However, to clarify some of the above, the reason you combine all of your CSS and JS into single files is to reduce overhead on the server for more things than file size. Every HTTP request takes up resources and time. So, if you transmit the same number of bytes with 1 http request instead of 10 seperate http requests, you can improve server performance and page load time substantially. Reducing the number of concurrent connections neccesary is the main benefit you'll see on the client side.

As far as managing your code when you're doing these sorts of things, it's a good idea to keep one set of code that you work off of, and then put it through some standard proccess when you go to deploy the code. QUIT DEVELOPING ON YOUR LIVE SERVER FOR GOD SAKES! Setup a simple CVS or SVN and keep all of your code stored in there. When you're ready to deploy, run it through whatever optimizers you want (strip out white space, combine css/js, etc..) Some compressors will even go through and start renaming variables to shorter names just to save a few bytes, but that's kind of extreme. After you've done your optimizations, deploy the optimized versions, but don't start developing off of them.

You need to set yourself up with a good dev/test/deploy/test again proccess if you want to get the most out of your site.