I have a page containing a large amount of controls that can trigger postbacks to the server. I know that it is not considered good practice to have a huge amount controls on one page, but the nature of my ASP.NET web application requires it. Seeing that I have a large amount of controls on this page, I make extensive use of UpdatePanels. I am storing ViewState in Session in order to reduce the response size of the page, which works beautifully.
However, with Fiddler I noticed that the 'asyncPostBackControlIDs' after the '__VIEWSTATE' part of the ajax response contains a list of every control of every UpdatePanel that can trigger a postback. This list is huge! It seems that this list doesn't change much per page, and thus it doesn't make sense to download the entire list every time a postback within an UpdatePanel occurs...
Is there any way to store the 'asyncPostBackControlIDs' on server like you can do with ViewState, or otherwise reduce the size of the 'asyncPostBackControlIDs' list?
AFAIK, there is no documented way for storing asyncPostBackControlIDs else where - further, I am very much in doubt if there can be such possibility because most probably those control ids would be required on client side to decide whether to do regular or asynchronous post-back.
You can set ChildrenAsTriggers property of UpdatePanel to false and register controls manually that are actually triggering the post-back - for example, you may have LinkButton/HyperLink that has java-script handler.
Further, perhaps you may able to reduce the list of controls that can cause post-back. For example, you can use anchors(a) instead of linkbuttons/hyperlinks and then set a hidden variable and then simulate a (hidden) button click. On server side, the value of hidden variable would indicate the actual control responsible for post-back. This way, you can have one button that is a post-back control for many other controls.
Finally, you are really a guy who want to have very efficient request/response streams then abandon ASP.NET control model and rather use ASP.NET MVC. Or at less scale, stop using Update Panels for AJAX (they do complete POST of page and almost entire page cycle is executed at server side) and use script services (along with jquery plugins) instead.
Lastly, you need to see the control ids size with the actual response size - for example, 5K long ids within 100K response may not be a large overhead. Reducing those ids would probably give you 5% savings (if possible) but are efforts for the same worth it?