And altough seperating page layout into several requests and serving them as well to the browser CAN be a speedup, especially because the visitors can see things before all parts of the page are ready.
But with a lot of complete page requests (with the smaller calls after that) this technique can be a slowing issue, because the webserver does not have to serve 1 request, but it has to serve maybe 5 or 10 requests. Think about an increase of visitors... The request rate grows exponentially, which will slow down the web server at the last place. I would only recommend this technique when you have the right parts of the site optimized and correctly cached.
Manuel Lemos - 2010-11-01 22:10:58 - In reply to message 1 from Cheater
No, that was not the idea.
With asynchronous programming you can perform several queries to a database in parallel within the same request. If your page is made of content retrieved using multiple database queries, in the end you can generate your page much faster.
You can already do that easily in Node.js. That is why Node.js was mentioned.
Tom Davidson - 2010-11-11 23:14:20 - In reply to message 2 from Manuel Lemos
I think this technique really depends on where your bottleneck is. If the bottleneck is that your webserver/database cannot respond to the request fast enough then this will make it worse, assuming this is not the case then it will improve the 'perceived' load speed while probably reducing the 'completely loaded' due to the way browsers queue up http requests.
It's speeding up the 'preceived load' speed that is the key to useability. For instance, if you can asyncronously load elements below the fold of the page after the elements above the fold the user sees what they think is a complete page, by the time they have scrolled down the rest of the content has loaded.