Source:
http://msdn.microsoft.com/msdnmag/issues/07/06/WickedCode/.
The main thing to take away from this article is that the UpdatePanel is a great control, but it definitely has its limitations when it comes to efficiency. Why? The article I linked to above does a fairly decent job of explaining why from a high level. The main, core, point to take away is that the UpdatePanel is good for purposes of simplicity; it will take whatever child controls are contained within it and make sure they participate in a partial post-back when one of them - or a control associated with the UpdatePanel - triggers a post-back event.
However, because the UpdatePanel must do so much for you it must believe that every control within it - or associated with it - could, potentially, need to be updated. These controls are mostly valid ASP.NET controls and, therefore, have ViewState that also must be maintained. In short, the UpdatePanel, in an attempt to be complete, will basically perform a pseudo full-postback to the server (even though the response message is optimized for use by the UpdatePanel). I guess, for a lack of a better analogy, think of the UpdatePanel as a mini page all to itself; I guess that somewhat holds up....
....so, bleh. If we're trying to be effecient, what do we do?
There are a couple options (one of which wasn't mentioned in the article but I would like to mention).
- Utilize PageMethods. PageMethods are static methods of your ASP.NET page class that are treated as web service'able methods. You can reach those methods through your script and the PageMethods proxy class: yet another proxy class auto-generated by the ScriptManager and its bretheren.
- Use a standard web service. If your ScriptManager has web services registered with it, it will auto-generate proxy classes for use when calling those methods from javascript. What this enables you to do is basically script against those methods.
- And, the one that was left out - use the asynchronous scripting methods of ASP.NET AJAX: http://ajax.asp.net/docs/ClientReference/Sys.Net/WebRequestClass/default.aspx
...being somewhat of a gearhead, I like the WebRequest class because it gives me absolute control over things; but it's definitely overkill for 99% of all uses (it's what Microsoft used to build the UpdatePanel and the asynchronous page-framework of ASP.NET AJAX). Basically MS "dogfooded" the WebRequest class for all async behavior in ASP.NET AJAX.