1. Obvious question with regards to optimization:
Have you enabled gzip traffic compression on the web-server?
Should get the time of serving content across the wire down a bit.

Otherwise the most common culprits in web app performance tends to be connectivity to the database (connection pools), non-optimum SQL queries, and unessecary iteration in the code through different types of lists/collections of data.
Also, having nicely normalized database tables are good in theory, but sometimes in practice it can create performance issues if you do lots of queries across several tables.

Hard to tell really without seeing code.
I'd suggest trying to put in time-logging in a test environment at different potential points of bottlenecks to pinpoint where you can get the most mileage out of optimization.
Optimizing blindly is mostly a waste of time, as you might be shooting "mosquitos with a shotgun" if you optimize some inconsequential spot in the architecture.

Posted at 1:41PM on Jun 1st 2007 by Wille Faler

2. I say keep the site design the way it is. I am getting good load times here in Honolulu. The design looks great so don't change that at all.

Posted at 2:52PM on Jun 1st 2007 by ET

3. I'm with ET. Unless you start feeling bumps in the road, keep on truckin'.

FasterFox is giving me 2.2, 1.7, 1.6 on consecutive homepage loads w/ cache cleared before each run. (I have the add-on set to turbo, btw.)

My SpeedTest.net bandwidth results as of 3PM EST were 9MB down & 2.5 up, just FYI.

Posted at 3:05PM on Jun 1st 2007 by Michael

4. Willie...

Good question, and yes, we are using gzip compression, and it's been serving us well. Pre-launch we went through and cleaned up any excessive iteration that we could find in the code, as well. We were thinking the same things you were.

Your point about the time-logging is a good one, and I've passed that along with the team. Now that we have 36+ hours of data, we have a lot more to go on, and can see the bottlenecks more clearly. Cleaning up some CSS has been helpful, as well.

Keep the suggestions coming! And thanks!

Posted at 3:19PM on Jun 1st 2007 by Chris Miller

5. Here is my suggestion:

http://www.marcelo.sampasite.com/brave-tech-world/How-to-make-Mahalo-load-faster.htm

Posted at 3:33PM on Jun 1st 2007 by Marcelo Calbucci

6. Just pushed up more updates for speed, should see a 300-500ms speed increase on page loads :) keep the suggestions coming though they are great!

Posted at 3:49PM on Jun 1st 2007 by Ray Slakinski

7. It's not specified (but is implied) in the linked suggestions by Marcello above, but try combining a bunch of your pretty-making images into a single .gif and use css background offsets to reveal the correct portion. This allows the browser to cache a single image and can cut down dramatically on the number of connections.

There are 7 little icon files that are all .gif right now. You could easily combine them in the suggested manner and save yourself the connection overhead of 6 calls and the resulting image would still be tiny.

Posted at 4:22PM on Jun 1st 2007 by Cameron Watters

8. 122KB @ 2.3s here.

Lots of comments, tabs and line feeds in the page. In my own sites I develop with all of those too, but I run all HTML through a custom app that strips it all out. That can save 2-3KB depending on the size of the page.

The 13KB GIF logo is far to big and looks jagged anyway. Switch to JPG and get it down to 3KB.

30KB for the mahalo_main.css is stiff, but it you've got to have it, you've got to have it. I'd look for redundancy that could be removed or triming down a new version just for the main page. First impression is everything, right?

I'd try to pack the wikibits.js or find a pre-packed version. 27KB is a bit much. Not compared to some JS packages, but still quite a bit.

All of those should trim about 20% of the page size off. Shrinking the HTML and CSS will give you the biggest gains right now since those have to be fully loaded before the browser can start requesting images.

Posted at 4:24PM on Jun 1st 2007 by -gary

9. It all depends on actual speed vs perception of speed, and in Mahalo's case I feel the latter is more important.

Turn off gzip compression. Users feel the site is faster if you're flushing your buffer as often as possible (around 4096 bytes) rather than waiting til you're done compiling their output. This will visually show the loading happening, which should still stay cosmetically appealing in your layout (you'll notice Digg does this). Its very simple to create an example of this, setup a huge page and show it with and without gzip compression - this perception makes all the difference.

Also, spreading your includes (images, css, javascript) across subdomains (up to 4) will better utilize HTTP 1.1 (read http://www.die.net/musings/page_load_time/). Being able to concurrently load 8 items vs 2 will give you a tremendous boost!

Personally, I wouldn't waste the time on cleaning the comments/spaces from the code. The ~2kb you'll save won't be felt by anyone.

I hope this helps!

Posted at 5:25PM on Jun 1st 2007 by Eric Caron

10. http://www.skrenta.com/2007/05/14_rules_for_fast_web_pages_by_1.html

Steve Souders of Yahoo's "Exceptional Performance Team" gave an insanely great presentation at Web 2.0 about optimizing website performance by focusing on front end issues. His powerpoint presentation is filled with some good stuff but here is a breakdown of his 14 rules for speedier page load times.

Make fewer HTTP requests
Use a CDN
Add an Expires header
Gzip components
Put CSS at the top
Move JS to the bottom
Avoid CSS expressions
Make JS and CSS external
Reduce DNS lookups
Minify JS
Avoid redirects
Remove duplicate scripts
Turn off ETags
Make AJAX cacheable and small

Get your tech team to go over this presentation to really give your site a boost.

Posted at 5:33PM on Jun 1st 2007 by Russell Heimlich

11. I don't like the design so much. Too much stuff is crammed to the left, and there's this huge spot 2/3 across the page that's all white. It's a huge strip of nothing right through the middle. It seems off and weird, especially in light of how many blogs exist that have content on the portion of the page. It's like I feel my brain has been trained to expect to see things there due to the amount of material I read online. Anyone else feel this way?

Posted at 8:34PM on Jun 1st 2007 by Russell Page

12. Pages have a nice simplistic yet aesthetically pleasing design. Load time isn't bad at all. Not entirely fond of the guide method. I think you should have specialists whose opinion weighs more, but still make it a combination of user and specialist selection. More in an ordinary search engine manner, with possibly the ability to click on a first link that takes you to the guide's page. Here is an article I wrote explaining my thoughts and plans for social search:
http://gamesecretary.com/community/blogs/david_mackey/archive/2006/04/24/77.aspx

Posted at 10:16PM on Jun 1st 2007 by David Mackey

13. Compress the JS files to save some KBs on size and then pack them together into one JS file to reduce # of HTTP requests.

Posted at 12:02AM on Jun 2nd 2007 by Jared Kim

14. If it's the perception of fast you're trying to tackle... have you thought about something like Akamai? Don't know where all your traffic hails from... but if it's sub second optimization you're chasing and feel certain

Posted at 12:18AM on Jun 2nd 2007 by Gerald Buckley

15. Jason, things you can do are:
. Compressed your javascipt and CSS files (they are not)
. Optimize the images. I use littleutils http://sourceforge.net/projects/miscutils/ and mogrify
. Split the content over more hosts (content1, content2, ..). This improves load times a lot as browsers can make only two connections
. Chain the javascipt and the css files if you can. Whatever platform you have will have modules for that.

Posted at 9:32AM on Jun 2nd 2007 by Klaas Naaijkens