Anthony, this helps a ton. Thank you. Can I offer an examples for learning purposes? When the page first loads, there is an intial dropdown populated from the database. Based on the selection of this dropdown, a second dropdown is populated from the database. Based on this second selection, 6 textboxes are populatted. The user may now opt to leave the text boxes as is, or make changes. At this point, the user starts to add user-controls to the page. This user control is simple: it's an .ascx file which contains one dropdown and two text boxes. The user adds one control, makes changes to the dropdown and two text boxes, then adds another. We don't know ahead of time how many controls will be added. Could be one. Could be twenty. Side note: It took me a LONG LONG time (days) to figure out how to alllow the user to keep adding controls and to maintain the previous controls each time a new one is added. I never did get it done on my own, and I ended up using a little third-party .dll to get the job done. I would still like a better solution. Problem: The page works fine and is speedy enough up to the point where the user starts adding the controls. With each control that is added, the entire page goes blank, and then re-builds slowly. Ok - I just did something after typing all of this above. I took your advice and examined the ViewState string in the source code. Before the first user-control was added, I copied and pasted the string into Word. It is about 5 lines long. Then I added a control and did it again. The ViewState string is now 26 PAGES long. Holy F!#g S!$##t !! Imagine after two, three, five, ten controls are added !!!! It looks like I have identified the souce of the slowness. So I am back to my original problem: How do I EFFECTIVLY add multiple instances of this user control, maintain them each, and not bloat the viewstate? Like I said, I have been trying to solve this now for almost a week. I have posted in multiple forms, including this one, and have had zero feedback. Ug. If anyone can help, I will UPS you case of malt beverage. Serious. For real. Casey -----Original Message----- From: thelist-bounces at lists.evolt.org [mailto:thelist-bounces at lists.evolt.org] On Behalf Of Anthony Baratta Sent: Wednesday, April 18, 2007 11:42 AM To: thelist at lists.evolt.org Subject: Re: [thelist] .NET: Generally speeding things up (Ajax?) 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.