There is a browser setting that'll affect the load time of any site: caching. In Tools-Internet Options, click the Temporary Internet Files "Settings" button. In the dialog box, under "Check for newer versions of stored pages", make sure it's set to "Automatically" or "Never". "Automatically" means that your browser will ask my server for the date/time of the latest version of each file, such as the button graphics. That takes a bit of time, but not as much as "Every visit to the page". "Never" means always go with the locally cached files. That would be fast, but then you might miss any updates.

Chances are, though, that your settings are OK. There's a...not so much a flaw, as a shortcoming, in the current design. Since this is GeekSpeak, I'll speak some Geek at you.

The present design consists essentially of standalone programs. That is, when you do something, like post a message or download a table of contents, the server has to load a program, run it, and unload it. That's not very efficient, but straightforward to program.

I'm working on a major redesign now to address this. Everything will be integrated into a "service", which is a program that's constantly loaded and ready to respond as soon as a request comes in. Requests will be routed through something called Microsoft Message Queueing, which, as the name implies, is a way of organizing and disciplining messages (requests for system services) through storing them in queues. This has a way of "batching up" related requests (like messages posted to one board) so that several requests can be handled at once to minimize overhead like regenerating the TOC after a post. A related benefit is "serialization", which avoids resource conflicts, when two programs try to access a single resource like a thread file, and one of them has to back off and wait while the first one uses the file.

Another benefit will be centralization of certain resources like the table of contents. In the current design, TOC-zero (the front page) is in a file that has to be opened and downloaded individually for each user. When you go into back pages it's even worse, as the server computes the back pages individually for each user, even if several users are going back to the same pages. In the future, TOC-zero will be cached in memory in a single place for download to all users. When somebody requests back pages, they will be cached too so that everybody can use them. When a post changes TOC-zero, the back pages will be flushed until such time as somebody requests a back page, when they'll be recomputed.

Ironically enough, one reason the present design is so slow is that I already use message queuing in one place, and I'm not using it well at all. It seems to take almost a second to create a new queue, and because the present design loads and runs programs each time you make a request, there's a one-second delay built into each and every operation while it creates a queue. Doh! The next design will create its queues once, at startup, and so there'll be zero delay for queue creation at each request. That one change alone should account for a noticeable speedup.

The timeframe? Well, a week ago I signed on as 50% partner in a startup to build a commercial Web site for lawyers, relying heavily on the boards to create a community where they can talk shop (unfortunately, sweat equity, like most deals in this post-crash era). That puts some urgency on redesigning the software to handle heavier traffic. It also obligates me to finish things such as membership and multi-tiered access to features. I'd say less than a month, two weeks if I can work on it fulltime.