If your focus is speed, then it really depends on what you are optomising it for - broadband or narrowband? If you will be using your site via a modem, and from the office where you have a fat pipe, i'd reckon you'd want to go the path of the lowest common denominator - narrowband.

From experience, if youre doing mainly narrowband, then you're looking at around 30Kb page sizes. The method in which you construct your pages is where you'd be looking at optomising.

Making the assumption your content is dynamic, I'd be looking at indexing strategies in your database, and indeed, what database platform you will be using, and how it is built and tuned.

As a general thing, keep your db handles open during the execution of your script, and perform multiple fetches on the same handle. Creating the handle is quite expensive, and I've seen many people open disreet handles for each time they want to access their database.

Use placeholders in your queries, the db will cache the statements and use the cached copy rather than "re-doing" a new query with hardcoded variables..

Use mod_perl. Its fast, but you have to have a decent amount of RAM. there are lots of tuning options there for you to make the most of.

The most obvious thing I can think of is keep your IO to a minimum - its expensive, however with everything there is a trade off. If you embed all your html, it makes maintaining your site harder, however if you template everything in existance, you will perform too many IO's. As a general rule I template my sites (HTML::Template) but generate some HTML to fill the gaps.

I read a study a while back which stated a human will consider sub 2 second lag as a contiguous operation, whereas when lag exceeds 2 seconds the operation becomes fragmented to the human mind, and it begins to break the concentration cycle. When i'm designing sites, I try get my pages to load in the sub 2s range as a general rule. Unfort I dont have the reference handy, otherwise I'd quote it.. ;-(

HTH

In my opinion, Javascript is best used for glue to hold together a web application, and for minor field validation (if at all). The load time of a page, if written in javascript coompared with perl/cgi, may increase, with the added disadvantage that the spinning globe (or whatever the browser uses to indicate waiting for a request) will stop while the javascript is rendering the page.

You will, of course, eliminate the perl compile-time delay :), which is less of an issue if your server has mod_perl or its ilk.

In terms of its use as glue, Javascript may be used to tie form fields together in a coherent way, such as disabling a set of controls depending upon the state of a checkbox or radio button, etc.

It also potentially has uses in rendering very large tables, since the download time can be shorter if the data is in javascript arrays than in generated HTML. This last use is controversial, since it obviously won't work if the browser has Javascript disabled.