[varun]

For AJAX-based web applications, following is what I'd suggest in making things very zippy for the user:

1. Concatenate your JS and CSS files. Don't send out several files over the wire to the browser - the browser can only make 2 connections at a time. Be careful about JS dependencies - order is imp. in JS.

2. Minify and then compress the JS and CSS. Use Dojo's Shrinksafe or the YUI Compressor to do this. It will strip out whitespace, etc - make the code smaller in size (In JS, every byte counts) and compress.

3. Now gzip the above. (Paul's article talks only about gzipping - if you do the above 2 steps as well, you'd improve the performance a lot more).

Write an Ant script to automate all the above on code commit and you are done. Try other methods like loading other elements in the background or after a tab etc is clicked - important to show something to the user almost instantly. Did this for Alertle.com, which was a 100% AJAX web app (no page refresh at all), and the initial size of the code being sent to the browser went from 700k to about 20k using the steps above :)

[varun]

4. Figure out browser caching - what to cache, how and for how long. Frequently changing code files - not a good idea to cache them for long, but images and other files, in most cases you only really need to download them once to the user's browser. Stuff to Google: etags and last-modified.

Improving site speed is a broad topic, and there would be other stuff on the server-side too where improvements can be made, like cached queries and using "prepared statements" to optimize the SQL.

[zepolen]

> the browser can only make 2 connections at a time

This is slowly becoming not true anymore, decent browsers like Opera and Firefox have defaulted to 8 for a while now, and IE8 defaults to 6.

Although all your points are still valid.

[uggedal]

While it's true that IE6 and IE7 can only handle 2 concurrent persistent connections per server, IE8 can handle 6.

Firefox 3 by default handles max 8 persistent connections per server, and max 15 connections per server in total (persistent and non-persistent).

This goes against RFC2616, but I guess the capacity of both servers and clients have increased enough the last 10 years to warrant such changes in default behavior across browsers.

[kragen]

The RFC2616 requirement was always a bad idea for users; for years I missed the Netscape feature that let you set this parameter to whatever you wanted; I left it at 20. (Was that up to 0.91N? I forget.) It helped out server software that made concurrent connections expensive, though.

[litewulf]

Another good argument in favor of doing so is that establishing a connection has a non-zero time cost. Further, your server may not have the workers to spare (so that extra connection is going to sit until the server's queue isn't backed up.)