As with any programming model, writing code to create an ASP.NET Web application has a number of pitfalls that can cause performance problems. The following guidelines list specific techniques that you can use to avoid performance bottlenecks.

The following guidelines list specific techniques that you can use to help maximize the throughput of ASP.NET Web applications. The guidelines are divided into the following sections:

• Page and Server Control Processing
• State Management
• Data Access
• Web Applications
• Coding Practices

The following guidelines suggest ways on how you can develop ASP.NET pages and controls that perform more efficiently.

While it is tempting to use the time- and code-saving features of the Web Forms page framework as much as you can, there are circumstances in which using ASP.NET server controls and postback event handling are inappropriate.

Typically, you need to create round trips to the server only when your application is retrieving or storing data. Most data manipulations can take place on the client in between these round trips. For example, validating user input from HTML forms can often take place on the browser before a user submits data to the server. In general, if you do not need to relay information to the server — to be stored in a database, for example — then you should not write code that creates a roundtrip.

If you develop custom server controls, consider having them render client-side code for uplevel browsers ( those that support ECMAScript ). By using server controls in this way, you can dramatically reduce the number of unnecessary hits to your Web server.

If you write code that handles server control postback processing, you will sometimes want different code to execute the first time the page is requested than when a roundtrip occurs. Use the Page.IsPostBack property to conditionally execute code depending on whether the page is in response to a server control event.

For example, the following code demonstrates how to create a database connection and command, then binds the data to a DataGrid server control only if the page is requested for the first time.

void Page_Load ( Object sender, EventArgs e )
   // ... ... do only on initial page load ...
   if ( !Page.IsPostBack )
      // ... set up a connection and command here ...
      String query = "select * from Authors where FirstName like '%JUSTIN%'";
      // ... fetch data ...
      myDataGrid.DataBind ( );
   }
}

Sub Page_Load ( sender As Object, e As EventArgs )
   ' ... do only on initial page load ...
   If Not ( Page.IsPostBack ) Then
      ' ... set up a connection and command here ...
      Dim query As String = "select * from Authors where FirstName like '%JUSTIN%'"
      ' ... fetch data ...
      myDataGrid.DataBind ( )
   End If
End Sub

Since the Page_Load event executes on every request, this code checks whether the IsPostBack property is set to false. If so the code executes; otherwise, it does not.

If you did not run such a check, the behavior of a postback page would not change. However, the code for the Page_Load event executes before server control events execute, but only the result of the server control events would render to the outgoing page. If this check were not run, processing would be performed for the Page_Load event and any server control events on the page. It can be easy to overlook this simple technique that can dramatically improve the response time for page request.

Review your application code to make sure that your use of ASP.NET server controls is necessary. Even though they are extremely easy to use, server controls are not always the best choice to accomplish a task. In many cases, a simple rendering or databinding substitution will do. The following example demonstrates a situation in which using a server control is not the most efficient way to substitute values into the HTML sent to the client. Each method sends the path to an image to be displayed by the requesting browser, but using server controls is not the most expedient method shown.

<script language = "C#" runat = "server">
   public String imagePath;

   void Page_Load ( Object sender, EventArgs e )
      //... retrieve data for imagePath here ...
      DataBind ( );
   }
</script>

<-- the span and img server controls are unecessary... -->
The path to the image is: <span innerhtml='<%# imagePath %>’ runat = "server" /><br>
<img src='<%# imagePath %>’ runat = "server" />

<script language = "VB" runat = "server">
   Public imagePath As String

   Sub Page_Load ( sender As Object, e As EventArgs )
      ' ... retrieve data for imagePath here ...
      DataBind ( )
   End Sub
</script>

<-- the span and img server controls are unecessary... -->
The path to the image is: <span innerhtml='<%# imagePath %>’ runat = "server" /><br>
<img src='<%# imagePath %>’ runat = "server" />

Use databinding to substitute literals instead ...

The path to the image is: <%# imagePath %><br>
<img src='<%# imagePath %>’ />

Or use a simple rendering expression ...

The path to the image is: <%= imagePath %><br>
<img src='<%= imagePath %>’ />

There are many other cases in which rendering or databinding are most efficient techniques to use, even when you use server control templates. However, if you want to programmatically manipulate a server control’s properties, handle server control events from it, or take advantage of view state preservation, then a server control would be appropriate.

Automatic view state management is a feature of server controls that enables them to re-populate their property values on a round trip without you writing any code. This feature does impact performance however, since a server control’s view state is passed to and from the server in a hidden form field. You should be aware of when view state helps you and when it hinders your page’s performance. For example, if you are binding a server control to data on every round trip, the saved view state will be replaced with new values obtained from the data binding operation, so disabling view state will save processing time.

Viewstate is enabled for all server controls by default. To disable it, set the EnableViewState property of the control to false, as in the following DataGrid server control example.

<asp:datagrid EnableViewState = "false" datasource = "..." runat = "server" />

You can also disable view state for an entire page using the @ Page directive. This is useful when you don’t postback from a page at all:

<%@ Page EnableViewState = "false" %>

NOTE: The EnableViewState attribute is also supported in the @ Control directive, which allows you to control whether view state is enabled for a user control.

To analyze the amount of view state used by the server controls on your page, enable tracing and look at the Viewstate column of the Control Hierarchy table. For information about tracing and how to enable it, see ASP.NET Trace Functionality.

There is a significant performance cost for disabling buffering of ASP.NET Web pages. For more information, see the Buffer property.