To all those who don't see the big deal in shaving 100 or 50 msec off page load time:
The Economic Value of Rapid Response Time
and the two articles that preceded it
"Factors Affecting Programmer Productivity During Application Development" IBM Systems Journal 23(1): 19-35 (1984)
"Interactive User Productivity" IBM Systems Journal 20(4): 407-423 (1981)
To summarize: the quicker the response time to the human, the better the human can stay focused, keep on track, and exploit short term memory, rather than returning to the task at hand from a restful or wandering state of mind.
In one text mode application, during a lengthy calculation process I put up a progress bar of *'s as it worked and then erased them when the calculation completed. As PC's got faster and I tuned my code, the recalculations dropped from typically 40 seconds, to 20, to 3, to less than 0.1 second. At that point I started getting calls from users that the "process" key stopped working.
However, if the user held down the process key, the row of *'s would flicker, indicating that it was working, displaying *'s and erasing them, within the typamatic repeat rate of the keyboard.
I added a "processing complete" text message to "solve" the "problem."
I would have thought that the following HTML performance tip might no longer be necessary, but it is:
Use explicit width tags in HTML table definitions. e.g. WIDTH="50%"
This is especially true if the table will be very long. Otherwise, the HTML renderer does not know how to render the table until all the content has been received.