PowerPages – High Performance Guidelines: Reducing PostBacks

How Can We Help?

< Back

Since Power Pages provide fine-grained control over PostBacks, data binding and caching, they can be leveraged to implement high performance pages.
The following article provides some guidelines and recommendations on how to achieve this.

This article addresses the topic of

  • Reducing PostBacks

See the links below for articles on other high performance topics:

PostBacks

PostBacks cause a page to be processed and refreshed due to some action. During a PostBack,

  • all the form data on the page (generally all editable control fields) are ‘posted’ back to the server,
  • the page is processed, and
  • then the whole page is received back from the server again.

The impact on performance

The server round-trip is costly and inefficient since reloading the entire page is seldom needed. The entire page is processed on the server which means there is a lot of wasted processing happening.

PostBacks are inherent in the underlying workings of ASP.Net WebForm applications and cannot be completely avoided, however, you can reduce the number of PostBacks that occur on your page through different strategies.

Alternatives

AJAX

Using some form of AJAX (Asynchronous JavaScript and XML) is generally the solution to avoid PostBacks, but the underlying mechanisms in ASP.Net WebForms make it a bit cumbersome to implement from scratch.

Asynchronous PostBacks

A better alternative is to use an existing implementation of asynchronous/partial PostBacks. Asynchronous/partial PostBacks still cause the form data back to be posted back to the server, but only returns the section of the page that should be updated. This avoids having to download all of the page markup from the server on every round-trip.

DevExpress Callbacks

The DevExpress control suite provides a similar mechanism to asynchronous PostBacks called Callbacks and many controls in the suite make use of them by default (e.g. paging sorting, filter in grids). Callbacks are initiated by a specific control (a grid for example), and only that control will be updated when the callback is complete.

Using DevExpress Callbacks

Following are some important considerations and recommendations to be aware of when using callbacks:

1. It is also possible to manually initiate a callback on a control via JavaScript:

[JavaScript] //handles the ValueChanged client-side event on ControlA function ControlA_ValueChanged(s, e) { ControlB.PerformCallback(); //initiates callback on ControlB }

2. On the server-side, callbacks are able to read the latest values of controls, but cannot update controls other than the initiating control.

3. Callbacks will still run the Page_Init and Page_Load events, so to avoid wasted processing time, wrap code blocks in `Page.IsCallback` checks to only run required code during a callback. The following code sample checks if a page is on its first load, in a callback, or in a PostBack.

[C#] if (!IsPostBack) { //first load of page } else if (IsCallback) { //in a callback (NOTE: IsPostBack will also be true during a callback) } else { //in a full PostBack }

A common inefficiency is to indiscriminately run expensive routines (e.g. data binding) on Page_Load. These could rather be run on first load and then explicitly when the data needs to be refreshed.

4. In order to update multiple controls, there are two options:

a. Trigger callbacks on multiple controls, for example:

[JavaScript] //handles the ValueChanged client-side event on ControlA function ControlA_ValueChanged(s, e) { ControlB.PerformCallback(); //initiates callback on ControlB ControlC.PerformCallback(); //initiates callback in ControlC }
Note: This approach provides flexibility but can quickly negate the performance benefit of callbacks since each callback needs to perform a server round-trip which includes some unavoidable overhead costs.

 

b. Wrap multiple controls in an DevExpress ASPxCallbackPanel, and then trigger a callback on the panel rather than individual controls:

[JavaScript] //handles the ValueChanged client-side event on ControlA function ControlA_ValueChanged(s, e) { CallbackPanelA.PerformCallback(); //initiate callback on panel containing ControlB & ControlC }

Grouping controls that need to update together requires more thought and planning up-front but will result in better performance since updates will share the overheads costs of the server round-trip.

Comments are closed.

This is the legacy version of the XMPro Documentation site. For the latest XMPro documentation, please visit documentation.xmpro.com

X