Hi icygod,

When full or asynchronous postback happens, then server performs basically same actions: evaluates view state, makes updates/calls to possible data base, etc. Application should figure out what takes most time and try to experiment with logic to improve that. If server actions take most time, then async postback (LoadOnDemand of WebTab) can hardly help there. If most time is consumed by rendering html and javascript initialize statements, then application may try to reduce number of controls involved in asynchronous postback. For example, if WebTab is a child of another tab and that tab is posted, then whole child-WebTab is recreated as well. If that happens, then application should avoid using nested tabs.

If application uses EnableAjax and application submitted several tabs, then all previously selected tabs are updated/refreshed by any async postback.
If that happens then ocasinal full postback will reset requests to process ViewState for previously selected tabs (UpdatePanels), and next async postback should be faster.

The extreme solutions is to impement custom 100% load on demand: load content only for a single selected tab. To do that, all ajax/async features of WebTab should be disabled and only LoadOnDemand is enabled. However, that implementation may require too much work. Specifically application should forget about built-into server viewState for child controls of WebTab. If application needs persistance of client values, then it should implement it on its own. For examle, get-set field values into database, or into Session, or similar. In case of complex multi-data objects/controls like selection or column moving in grid similar is next to impossible. Application also might lost all server events, so it should get all changes/events directly from hidden fields of Form.
If application needs async postback, then it may insert that 100%-full-postback-loadOnDemand WebTab into UpdatePanel.