Use YSlow to understand how you can optimize your website and follow all webpage optimization best practices.

YSlow analyzes web pages and why they’re slow based on Yahoo!’s rules for high performance web sites.

Visit YSlow official website for more info: http://yslow.org

1. Rely heavily on caching at the browser level (meta-tags — use Firebug or equivalent to evaluate your calls to the server and verify resources are being cached on the client side).
2. For dynamic content, use AJAX w/ JSON (not XML) to minimize browser traffic and post-backs. (Or experiment with websockets if you can guarantee which browser they are using).
3. Experiment with coding more logic within the JavaScript itself (JS MVC?) — again to eliminate calls to the server.
4. High compression on any images
5. Minify any JavaScript used

You’re goal is going to be to pass as little to and from the browser as possible in the least amount of call-backs to the server. See Yahoo’s Guide as well.

I think Watson needs to qualify his point #5: Minimize JavaScript. I think what he means with is point #3 is if you have a page that needs to build a lot of HTML around a list of very small bits of data, you can build the data into an array in JavaScript and have it build that part of the page using Document.write(). For instance, on a page that has to list many long strings separated by commas or by semicolons, you could just list the strings once.

var emailAddrs = new Array("[email protected]",
    "[email protected]",
    ...
    "[email protected]");
function showEmailAddrs(semicolon) {
    var innerHtml = '<a href="mailto:javascript:hideEmailAddrs();">Hide email addresses</a><br />n<span class="normal">';
    if (semicolon) {
        innerHtml += emailAddrs.join('; ');
    } else {
        innerHtml += emailAddrs.join(', ');
    }
    innerHtml += '</span>';
    document.getElementById("emailAddrs").innerHTML = innerHtml;
}

With a long list, you can see how this would save almost half the size. If the JavaScript built <option value="123"> tags around a few thousand strings, you can save even more space. As others have said, avoid large images. I would also have to add:

• Theories only get you so far. Believe what you time, and time everything. I like to make each timing test 10 times, arrange the results in ascending order and average the middle two times. Record your time before you start optimizing so you are sure that you are making things better and not worse. I time the server, I time the client… you get the picture.
• Use the built-in timers in the “Developer Tools” in most browsers.
• Don’t use HTTPS unless you have to – it turns off browser caching.
• Time the difference between using separate CSS and JavaScript files vs. embedding them in every page. For HTTP, separate should be faster (it can be cached), HTTPS, embedding should be faster (it’s one less request).
• Don’t forget the server side. Most of the projects I’ve had to fix on have been slow waiting for the server to read the same data from the database 3 or 4 times, and then throw it away and use different data to build the screen!
• You can experiment with having your web server compress responses. I think there’s a gzip compression option on most servers that browsers understand.
• If you have a big image (with HTTP), use the same big image on every page so the browser can cache it.
• Learn the differences between GIF, PNG, and JPEG. Each works best for a different type of image. If you have a large, very faded background, you can compress the heck out of it in a really low-quality JPEG and if the contrast is low enough in the original image, it will look fine.
• Compress your CSS. I’ve had good luck with lotterypost.com/css-compress.aspx recently. I do add a line break after ever } so I can still read it.
• Eliminate unused CSS, comments, whitespace… I always put a line break after a <br /> and you can’t always trim whitespace from inside elements without causing trouble. But you can remove consecutive whitespace characters anywhere.
• Write simple HTML. Use fewer tables, fewer tags, less formatting whenever possible. A strong knowledge of HTML and CSS is your biggest ally here.
• Don’t use spacer images (from my blog).

These suggestions work with any major platform. I might look for something that gives you a lot of control over your HTML. I’d stay away from JSP and Struts tags due to the difficulty of managing whitespace. If you are into Java, you could look at JRebel to automatically compile servlets, but most people use Spring with JSF, which I haven’t tried. Ruby/Rails is great for rapid prototypes, but not for your final application. A good portion of the web runs on PHP, so how bad can it be? I’m into Scala these days, and have been meaning to check out Lift (for secure sites). Play looks pretty sweet to me for a public site, but as I said, I’m a little biased towards Scala right now. There are so many choices!

Good luck!

What optimizers won’t do for you is minimize the use of large multimedia (graphic mostly) files. Unnecessarily oversided graphics and lots of them typically accounts for most of the waiting times on dial-up. A minimalist approach to both the number of separate downloads and their size, would be good.