Raj Kaimal

So you mean instead of doing 300 small requests, just do one big one? That would make a whole lot of sense to me.

Especially when you think the HTTP header may be 100 bytes or so, if the requested data isn't much bigger than that, then you're just wasting all that extra overhead.

I can't tell you what our site is until it's released on Monday, but I CAN tell you that our architecture is something similar to what you're talking about. Well, we at least get rid of having soooo many requests on the first load.

http://on10.net

That's just a teaser site for now. Watch for the real thing to go live on Monday (the 13th).

Basically, what we did was make it so that our web services just render asp.net controls and send back the html. This works great for our ajax stuff, but when the page loads, it's just renders those controls instead of making ajax calls, so basically just the css files, js files, images and html comes down and that's it.

The only downfall to this is that the server does more work instead of sending some of the work down to the client, but we've found that this method works out really well and I can pretty much promise that the number of requests that happen on our site will be a lot less than all the sites you listed. And no, if you're trying to guess what our site is all about, it's not really anything like the sites you listed.

Check back on my blog and the on10 site for more next week. :)

If you analyze the requests closer, you will notice that the majority of the small requests are images (e.g., dropping images, there are about 30 requests for the initial state of the page). Also, due to temporary caching issues, the majority of the images are requested multiple times.

However, your point is well made and we are still "experimenting" with finding the best balance. On the latest windows live release, the Live.com team included the initial user state directly on the page. As a pattern, we are also exploring how to batch smaller data requests (in addition to potentially including more data directly in the page).

I expect we will continue to tweak our approaches to find the best balance for our scenarios to provide the best overall experience (balanced between initial load and subsequent visits), intelligently leveraging the 2 connection limit (including splitting content across servers), and leveraging the caching benefits of the client.

For example, while the initial load time may be longer, with smart caching and properly aging data requests, subsequent usage can potentially be much faster as you only need to load the differential.

There are a few other trade-offs for both approaches to consider, but this is an interesting discussion where I believe there is no single universal answer.