Improving ASP.NET Performance Part 6: Server Controls

In our previous article in the series Improving ASP.Net Performance we discussed optimizing individual aspx pages. Now it’s time to look at Server Controls.

You can use server controls to encapsulate and to reuse common functionality. Server controls provide a clean programming abstraction and are the recommended way to build ASP.NET applications. When server controls are used properly, they can improve output caching and code maintenance. The main areas you should review for performance optimizations are view state and control composition. Use the following guidelines when you develop server controls:

Identify the Use of View State in Your Server Controls

View state is serialized and deserialized on the server. To save CPU cycles, reduce the amount of view state that your application uses. Disable view state if you do not need it. Disable view state if you are doing at least one of the following:

·         Displaying a read-only page where there is no user input

·         Displaying a page that does not post back to the server

·         Rebuilding server controls on each post back without checking the postback data

Use Server Controls Where Appropriate

The HTTP protocol is stateless; however, server controls provide a rich programming model that manages state between page requests by using view state. Server controls require a fixed amount of processing to establish the control and all of its child controls. This makes server controls relatively expensive compared to HTML controls or possibly static text. Scenarios where server controls are expensive include the following:

  • Large payload over low bandwidth. The more controls that you have on a page, the higher the network payload is. Therefore, multiple controls decreases the time to last byte (TTLB) and the time to first byte (TTFB) for the response that is sent to the client. When the bandwidth between client and server is limited, as is the case when a client uses a low-speed dial-up connection, pages that carry a large view state payload can significantly affect performance.
  • View state overhead. View state is serialized and deserialized on the server. The CPU effort is proportional to the view state size. In addition to server controls that use view state, it is easy to programmatically add any object that can be serialized to the view state property. However, adding objects to the view state adds to the overhead. Other techniques such as storing, computed data or storing several copies of common data adds unnecessary overhead.
  • Composite controls or large number of controls. Pages that have composite controls such as DataGrid may increase the footprint of the view state. Pages that have a large number of server controls also may increase the footprint of the view state. Where possible, consider the alternatives that are presented later in this section.

If and when you do not need rich interaction, replace server controls with an inline representation of the user interface that you want to present. You might be able to replace a server control under the following conditions:

·         You do not need to retain state across postbacks.

·         The data that appears in the control is static. For example, a label is static data.

·         You do not need programmatic access to the control on the server-side.

·         The control is displaying read-only data.

·         The control is not needed during postback processing.

Alternatives to server controls include simple rendering, HTML elements, inline Response.Write calls, and raw inline angle brackets (<% %>). It is essential to balance your tradeoffs. Avoid over optimization if the overhead is acceptable and if your application is within the limits of its performance objectives.

Avoid Creating Deep Hierarchies of Controls

Deeply nested hierarchies of controls compound the cost of creating a server control and its child controls. Deeply nested hierarchies create extra processing that could be avoided by using a different design that uses inline controls, or by using a flatter hierarchy of server controls. This is especially important when you use list controls such as Repeater, DataList, and DataGrid because they create additional child controls in the container.

For example, look at the following Repeater control.

<asp:repeater id=r runat=server>


  <asp:label runat=server><%# Container.DataItem %><br></asp:label>



Assuming there are 50 items in the data source, if you enable tracing for the page that contains the Repeater control, you would see that the page actually contains more than 200 controls.

The ASP.NET list controls are fairly generic and may not be optimized for your scenario. In situations where performance is critical, you can choose from the following options:

  • If you want to display data that is not very complex, you might render it yourself by calling Response.Write. For example, the following code fragment would produce the same output, as noted earlier in the section.

for(int i=0;i<datasource.Count;i++)


  Response.Write(datasource[i] + “<br>”);


  • If you want to display more complex data, you can create a custom control to do the rendering. For example, the following custom control produces the same output as noted earlier in the section.

public class MyControl : Control


  private IList _dataSource;

  public IList DataSource


    get {return _dataSource;}

    set {_dataSource=value;}


  protected override void Render(HtmlTextWriter writer)


    for(int i=0;i<_dataSource.Count;i++)


      writer.WriteLine(_dataSource[i] + “<br>”);




In our next article we’ll discuss optimizing Data Binding.