Improving UpdatePanel Performance with Trace=”true”
Yes, yes, I know that UpdatePanels aren’t elegant AJAX implementations. I know that some consider them cheating and worthless. But I also know that they are easy to use and they work darn well, so I will continue to use them for a lot of applications.
Like any complex technology that is dumbed down to be easily consumable, there are some trade-offs that require some level of knowledge to leverage correctly. Microsoft has done a great job over the past few years of taking super complex technologies and making them very easy & accessible. The trade off here is that by doing that a lot of consumers that utilize Microsoft’s offerings take the easy approach to the extreme and don’t bother learning anything about the technology; that is where they get in trouble. Microsoft can only dumb things down so much, but at the end of the day you still need to learn about the technologies to take advantage of them.
ViewState & the UpdatePanel
The ViewState in an ASP.NET page keeps track of the status of your page when it is submitted to the server. Why have a ViewState in the first place? Good question; and the answer is that web pages are stateless, the ViewState (as well as the Session & Caching) are ASP.NET’s way to add statefullness to a stateless technology.
Here is a great explanation from an MSDN article:
There's really nothing magical about ViewState. It's a hidden form field managed by the ASP.NET page framework. When ASP.NET executes a page, the ViewState values from the page and all of the controls are collected and formatted into a single encoded string, and then assigned to the value attribute of the hidden form field (specifically, <input type=hidden>). Since the hidden form field is part of the page sent to the client, the ViewState value is temporarily stored in the client's browser. If the client chooses to post the page back to the server, the ViewState string is posted back too. You can actually see the ViewState form field and its postback value in Figure 2 above. Upon postback, the ASP.NET page framework parses the ViewState string and populates the ViewState properties for the page and each of the controls. The controls, in turn, use the ViewState data to rehydrate themselves to their former state.
http://msdn.microsoft.com/en-us/library/ms972427.aspx
When a PostBack occurs in an UpdatePanel the page’s entire ViewState is passed to the server, updated, and then the updates are passed back down to the ASP.NET page. So the size of your page’s ViewState has a HUGE effect on the performance of your UpdatePanel postbacks.
If you want to learn more about the ViewState in general, here is a great MSDN article:
http://msdn.microsoft.com/en-us/library/ms972976.aspx
Knowing this little tidbit can really help you to improve your UpdatePanel performance by tuning the size of your ViewState. Microsoft has already done a lot of optimization with the UpdatePanel, such as PartialRendering by default. However, if you have a bloated ViewState nothing is going to help you improve performance as much as cleaning the bloat. The less information that needs to be posted back to the server by the UpdatePanel the better your performance will be.
Using ASP.NET Form Trace
A little known feature of ASP.NET Web Forms is the Trace property. If you set Trace=”true” on your web form you get a whole plethora of information about your page when you run it. 
There is a bunch of valuable stuff there, but for this discussion we want to focus on the ViewState Size Bytes.
Notice that when you enable Trace on your page ever control & object’s ViewState size is listed in the trace information. By scanning the trace output of your page you can quickly identify those controls that are causing ViewState bloat.
Reducing the ViewState Bloat
There are a myriad of options when it comes to techniques to reduce the ViewState size for a given page; I will just highlight a few. The ViewState is enabled by default for each page and control, so if you don’t need the ViewState for a given page or control you can easily ratchet down your ViewState size by simply disabling it.
Code-Behind method for disabling the entire Page ViewState:
Page.EnableViewState = false;
Page level directive method:
<%@Page EnableViewState="False" %>
And then you can also disable per control:
<asp:GridView ID="GridView1" runat="server" AutoGenerateColumns="False" DataSourceID="SqlDataSource1" EnableViewState="false">
Also, if you remove the runat=”true” tag from any of your controls that don’t need it the ViewState for those controls will be eliminated. A good example of this is if you are using <asp:Label> controls so you can format text with its CssClass property. Using a simple <span class=”MyCssClass”> instead of the <asp:Label> will save you that control’s ViewState bytes.
I hope this helps.