It's all about performance
I've mentioned performance a couple of times before in the context of specific technologies (SQL Server and Javascript) but looking at a recent rebuild of a site I'd been involved in it occurred that there are a number of things that can affect performance that are easy to overlook yet can have fairly drastic results.
Every roundtrip costs time. If you can bundle everything into a few requests it helps performance. Of course too much bundling (eg putting your javascript and CSS inline) doesn't always help long term (as it makes caching hard) so there's a balance.
Combining Javascript and CSS files into fewer larger files can help, but if there's a lot of differing usage depending on the page or user type across the site consider dynamically combining and caching these (so you only have to work on the master files and let the server generate and deliver cachable specifics).
On the homepage it might be worth having them inline, and also reference them (via an onload) as external scripts, so they're pre-cached for subsequent pages. If you set a cookie when the external files are loaded you can determine when the page is accessed if you should put the code inline or rely on external cache to speed things up.
Every time you have to do a DNS lookup to find a domain name it takes time that could be used to deliver content. If you include the full URL in every href then lots of DNS checks can occur. Most browsers cache these, but how many and for how long. Having lots of lookups required on the homepage can reduce the impression of performance. Flip side though is that most browsers will by default only make a certain number of requests of a given server, so you may be well served by splitting content over more than one domain name (but only 1 or 2... too many and the lookup overhead outweighs the value of the technique)
If your business relies on getting content to users and you can get that content intelligently cached and closer to the user, it's work paying a Content Distribution Network like Akamai to help. Some of the larger ISPs today with multiple data-centers can even offer a CDN capability without needing to use one of the big players. There are even free peer-to-peer CDNs like Coral available (and really easy to implement). Use tracert - count the number of hops to random users in your server logs... how far away (and how long a round trip) is you request/response reaching?
You know how static your content is going to be. Tell the proxies, caches and users browser so it can make an informed decision. If they can cache an image forever... let them. You can always cache bust by changing the filename if you need to refresh something urgently.
Ideally in the <head> where it will be loaded before the rest of the page. If you're not going inline use <LINK...> not @import. These tricks avoid the funky page flicker as the content loads and then the style gets applied.
If you don't need it straight away get it out of the way. Parsing javascript will block the page rendering and so make things appear to run slower. If you need a function straight away define it in the <head> and call it with a <body onload="..."> but minimize what you put there
If the rendering engine has to do some heavy lifting before deciding what colour to make your text it's going to slow things down. Make it explicit and use rules when you're generating the page to select appropriate classes for content
The less you send over the wire the better. Whitespace is not your friend in production (though helpful for debugging). I like the w3compiler from Port80 but there are many options out there (and for dynamic page generation I wrote some ASP code that compressed news stories to the bare bones). Most servers can also zip content on the fly (either on-demand or zip and cache for static content) so make sure it's enabled
Put your content where you say it is. Every time a page or content item needs to go hunting it's a wasted round trip. Don't rely on the server to hunt for a document, point to it explicitly. Look through your server logs for 300 status codes - every one of them is a wasted round-trip
So... what should you do next?
The biggest / easiest wins come from making sure your content is optimized - compressing and making sure your Javascript and CSS are cacheable (especially relevant in the JS rich world of Ajax apps) and referenced from the right part of the page. You can control that no matter how or where you're serving content.