You hit on what I consider the biggest weakness of the dotNet Framework, the full dependency on post-backs for EVERYTHING. It just does not scale well with complex forms. One option is to move to AJAX calls, but then you are doing an end run around the State Management that dotNet provides you. And therefore you will be leaving behind some of the functionality that the controls give you because they are heavily dependent upon the state management and post-back for many of their "features". First thing I would do is check how your page is built. You should only be building your main controls ONCE when the page is originally built. Then on each post back you should only be working with the changes necessary to update your page and add new / take away controls - based on user selections. Try and make use the State Manager as much as possible so you are not recreating and re-populating controls unnecessarily with data with every post back. How big is your viewstate when it's rendered as HTML? (The hidden form element "_viewstate".) The size of that sucker can also be a drain on rendering because it can get frigging huge! dotNet 2.0 is suppose to keep that element on a diet - but sometimes it still can get out of control. So, make sure you only use Web / HTML Control when it's absolutely necessary. Don't make anything a control that you don't need to manipulate server side. For example we generate HTML Data grids server side and stuff them into Container DIVs, then send to the browser. We always turn off ViewState for those controls because we don't care about maintaining state for that control - it's display only and when changed vis AJAX we don't want the server attempting to recreate the original data stored in that container because it's mostly likely changed with out the server knowing about it. So we take the very very small performance hit and rebuild that Data grid (via it's DB stored data) with each page load - no matter what. But what that gives us is a smaller _viewstate - which gives us a faster rendering speed on the browser side. (Robbing Peter to pay Paul, but the server's grab and build of the data is much much faster than the browser's grab and render when the browser has a large viewstate to contend with.) Now if your page is very "heavy" with HTML as a result, try and only build build your dynamic controls when needed, versus hiding them on the page some where - save on page weight. Try and make sure your page construction is as simple as possible to keep rendering time down to a minimum. Don't over nest DIVs. Fix the width of everything. These types of issues is exactly why I ditched the dotNet Web Controls and only use the HTML Controls. And I use AJAX when I need the HTML Element / HTML Control to talk to the server - never multiple post-backs like the way dotNet wants you to. The only time my pages post back in the dotNet way is for final submittal of the form. All other posts, when necessary, are AJAX driven. Yes, this means I don't get full value of the State Manager, but I get better response time and less hassle because I'm more in control of the page - only updating targeted sections with out a full page refresh. Hope that helps, your mileage may vary. > On Apr 17, 2007, at 6:22 PM, Casey Crookston wrote: > > I have a general "best-practice" question. I have a page that has > lots > of textboxes, dropdowns, and labels inside of placeholders and > controls. > It also loads many dynamic controls into various placeholders, many of > which use auto-postback. After a while, the page gets very big, and > each time the user does an auto-postback, it can take a while for > ALL of > these controls to re-load from viewstate. > > What's the best way to speed things up? Do I need t learn Ajax?