Speed Up Your ASP.NET Pages (Continued)

5) Limit ASP.NET Server Controls
Exceptions and session state impose overhead. Surprise—so do ASP.NET server controls. They require server-side support, which leads to communication between your server and the client to support the control, and resource consumption on the server. Avoid the temptation to drop the server control onto your form and forget about it. In fact, you might be better off with a regular HTML control. Use the server control only if you plan to control the properties of a control programmatically, use view state to hold data values of the control, or handle server-side events generated by the control.

6) Precompile Your Apps
Every time you change a page on your Web site (and its containing assembly), you need to recompile that page when a user first touches it. We've all noticed this during development: You make changes, press F5, and wait until the page is compiled and loaded. There is considerable discussion about whether this is really a problem that requires much attention.

If you have a large Web application, you have several approaches to performing pre-batch compilation to get the entire site compiled and ready to run. First, there are several utilities available that will walk the pages of your site and do an HTTP request for each page. This forces ASP.NET to load and compile each page. This "automated" process might not work if a page requires authentication. Second, you can browse the site manually after you upload it to the server. The drawback is that it can be difficult to "touch" every page if your site has hundreds of pages. If you can't touch every page, you could visit the main pages of the site that give a user the first impression of your site. A slow first page is a poor introduction, but a slow-loading page later in the process is not such a turnoff.

First impressions are critical because unless you have customer loyalty, today's users will go somewhere else rather than wait for a poor-performing site. The question about precompiling rests on the premise that only the first user of thousands of users will see a delay in loading. Is it worth the extra work and concern for such little return? If you're concerned, Microsoft has the solution for you in the next version of .NET. Whidbey will have a precompiler ASP handler you can use to get the most performance from your site by reducing the compile time as a user loads each page.

7) Use ASP.NET Caching
Cache the server-based data that's used repeatedly and doesn't change between each request from a page. You must strike a balance between what data to cache, when, and for how long. Don't cache too many different items. You pay an overhead penalty for maintaining the cache, and you pay an extra penalty as the system keeps the cache up to date tracking all those bits and pieces (see Figure 2).

Don't put items in the cache that expire quickly. The maintenance overhead might negate the benefit of caching if ASP.NET must update the cache with fresh data every second or two. Unfortunately, no hard and fast rule says, "If the item in the cache updates less than every X seconds, don't put it in the cache." You can implement caching on your ASP.NET pages easily by using either page directives or Response object methods.

Placing this code in your ASPX page tells ASP.NET to use a page directive to cache page output for 60 seconds:

<%@ OutputCache Duration="60" 
VaryByParam="None" %> 

The VaryByParam attribute causes a conditional update of the cache. Subsequent page requests are fulfilled using the cached information. ASP.NET rebuilds the page and updates the cache after the specified time. You can accomplish the same action with this method call in your page code:

Response.Cache.SetExpires(DateTime.Now.A
ddSeconds(60))

Perhaps your site is an online catalog with several categories of products. Users browse through the categories, looking at products. The pages include a list of products—each with a picture—in each product line, and you've cached different pages for different product types. You know most customers will request a look at the section dealing with your most popular product line, for example, and you want to cache versions of the page for these products and for memory. Add this directive to your page:

<%@ OutputCache Duration="60" 
VaryByParam="category" %> 

ASP.NET caches your mobility page when customers make this request:

http://www.yoursite/products.aspx?category=mobility

A request for the memory product line caches a second page along with the mobility product page. Future requests use that cached page for the next 60 seconds. The caching is flexible enough to let you cache on multiple values:

<%@ OutputCache Duration="60" 
VaryByParam="category;zipcode" %> 

If your product page were to vary by customer ZIP code, the directive would create different pages based on both criteria.

You can see from this example the extensive, flexible control you have over page caching. You have many opportunities for enhancing site performance. Caching, in particular, improves the performance of most Web sites—as long as you use it judiciously.

About the Author
Dan Fergus is the principal technologist at Forest Software Group, which specializes in .NET Compact Framework applications. Dan is also a trainer and consultant, covering the Compact Framework and .NET in general. He has written many articles and coauthored The Definitive Guide to the .NET Compact Framework (Apress). Contact him at .