Many developers don't take the time to structure their applications for great performance. I'm going to present some tips that I have found here
for writing high-performance asp web applications:
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
- 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.
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
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, consider 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.
Table 6.2: Partial Repeater Control Hierarchy
ASP.NET list controls are designed to handle many different scenarios
and may not be optimized for your scenario. In situations where
performance is critical, you can choose from the following options:
I hope the provided information is helpful.