Walking the talk: There are lot of pundits on the internet expressing their view on how to improve performance on high volume web sites. Few have actually written code for high volume web sites.

According to Google's Webmaster tool, the BestPicker web site is faster than 90% all websites on the internet (not counting the time it takes to load all of Google's Adsense advertisements). The BestPicker web site makes heavy use of JavaScript, CSS, and large database-driven tables -- yet has near desktop application-like performance.

The BestPicker web site is actually one large application (Java servlet) generated from the Konsensys DreamBeans tool. So, how does a general purpose code generator generate such a fast running web site?

The Konsensys DreamBeans tool relies on a few performance principals that you can easily implement in your web sites.

1. Minimize round trips between the browser and the server.
2. Minimize the amount of "stuff" that is uploaded to the browser.
3. Balance the amount of computation between JavaScript on the browser and code running on your server.

Now, I will go into a little detail on each of these points:

1) Minimize round trips between the browser and the server.

1. If you look at the source HTML on the BestPicker web site you will see that the style sheet and JavaScript code are all inlined. The Java servlet bundles all the CSS and JavaScript into one large string so that it does not have to be reconstructed each request. The servlet just outputs that perconstructed string from memory when requested, which is at least 10 times faster.
2. Don't change URLs. If you use the same base URL, your browser will likely re-use locally cached images rather than going to your server.
3. You might have noticed that the BestPicker website uses diamond images for the rating system. Those are not uploaded images. They are entity characters (e.g., &daims;) that browsers already have. There are many such character images that browsers already have.
4. If possible, configure your Web server to cache images, flash, etc. so that the server does not have to read them from storage again. Use different names for changed images, flash, etc. rather than updating the images or flash. That allows the browser to more quickly decide whether to use the cache or make a new server request. The Tomcat web server for instance does not have a configurable cache control policy. However, Tomcat often sits behind a "proxy" webserver like Apache, where you can configure the cache control.

2) Minimize the amount of "stuff" that is uploaded to the browser.

The best way to do this is to use AJAX to only upload and change the pieces of a web page that need to change. For example, the Konsensys DreamBeans tool generates code such that all the CSS and 90%+ of the JavaScript is only loaded once.

When using AJAX, DO NOT use DOM/XML calls to replace the contents of more than a few HTML elements. If you are replacing are large portion of a web page, e.g., replacing one data entry form with another form or replacing one large table with another table, then use responseText/innerHTTML replacements instead. Replacing the contents of a lot of HTML with DOM/XML is 100 to a 1,000 times slower than using innerHTML for large replacements. And using DOM/XML to replace a large number of elements requires writing much more JavaScript than simply replacing the innerHTML of a single top-level element.

Another way to minimize the amount of "stuff" to upload is to strip out space characters and obfuscate JavaScript with shorter variable and function names. The Google GWK toolkit does this. But, if you are only uploading your CSS and most of your JavaScript once and using AJAX to replace the rest of your page contents, then the improvement of stripping and obfuscating is minimal. It also has the disadvantage of making it much more difficult to debug the CSS and JavaScript.

You can often configure your web server to "deflate" your web pages (compress them). However, you must carefully balance the time it takes a web server to compress a file and for the browser to decompress a file versus network bandwidth and latency. For example, compression is important on low bandwidth network connections (such as using a modem, which except for rural areas are now obsolete) or where there is large network latency (latency is caused by large geographical distances, e.g., you are using computer in Tokyo, Japan to access a web server located in New York City, US, where it takes a long time for the electrons to move packets between locations). If you have a high bandwidth connection with low latency, compression might actually be slower than just sending the raw web pages.

3) Balance the amount of computation between JavaScript (Java applet or Flash or ActiveX) on the browser and code running on your server.

You will notice that home page of the BestPicker website has a tree structure for selecting products. All the computation for expanding/contracting the tree is done on the browser via JavaScript. It's a medium amount of JavaScript, but it is only loaded once. And doing the tree expansion/contraction computation on the browser allows the web server to serve more pages. I try to offload as much computation to the browser as is practical.

All applications running on the PC accessing a "dumb" database server is known as a thick client/thin server. When browsers became popular, the paradigm shifted to a thin client/thick server, where most of computation is done on the server and simply displayed on the "dumb" browser (much as time-share servers used to display on "dumb" terminals many years ago). I think the world pendulum is now shifting to a more balanced, medium client/medium server in terms of computation load.