Optimizing website performance is a challenging task. Websites are composed of many moving parts - both on the client and on the server - and optimizing performance requires a multi-faceted approach that addresses potential problems in all moving parts. Performance bottlenecks are caused by an array of problems, from browser mechanics to server configuration, and a clear understanding of how to address these problems will provide AJAX ASP.NET developers with the tools necessary to make any website faster.

What Does It Mean to Optimize Performance?
Before any discussion about improving website performance begins, it's very important to ensure a clear understanding of what "performance" means in this context. With websites in particular, it's easy to confuse the terms "performance" and "scale." Both are important, but each focuses on a separate aspect of building a high-quality website.

Performance, as we are using it in this context, refers to the speed or responsiveness of a website. Minimizing page load times, making operations with data grid controls fast, and in general reducing the amount of time your user spends waiting on your site all fall under the umbrella of performance. If you have a client or boss who wants sub-second page load times, they are asking you to deliver performance.

Scale, meanwhile, deals with the idea of ensuring that performance is maintained as more people use your site. A website might load in less than a second when five people are using it, but when 5,000 people start hitting it, a site will start to slow down, or worse, if good scalability techniques are not used. Therefore, poor scalability will lead to poor performance as your site's usage grows, so it's important to address both scalability and performance for a high-quality site. There are many unique techniques for addressing scalability, and some actually sacrifice performance in exchange for better handling of load.

Fortunately, while the techniques explored in this article focus primarily on making websites load faster and feel more responsive, most also have a beneficial impact on scalability.

How Do You Measure Performance?
In order to determine if any technique has a positive or negative effect on performance, you must know how to measure performance. No performance improving technique is a silver bullet and, depending on the infrastructure and the geographic distribution of site users, different techniques will yield varying degrees of improvement.

The key performance factor generally measured is page load time, either of an initial load or a load that occurs as the result of a page action, such as clicking a button. Basic testing can be performed with free tools like Firebug in Firefox or Fiddler. These tools will clearly show you important information about factors that impact page performance, and they will also provide a basic indication of total page load time, though these tools generally fail to capture the time a page takes to fully initialize in a browser. There are also free tools like Google's Page Speed plug-in for Firefox and Yahoo's YSlow plug-in that try to analyze your site pages and provide guidance for improving performance. All of these tools are good for rough, relative performance measurements, but the results are not accurate measures of performance from an end user's perspective.

To perform more accurate testing, measurements must account for the variables that impact your users, such as latency. If your site is accessed by users around the world, and you have a single server in Texas, performance will be perceived very differently by users in the U.S. versus users in Asia. Connection speeds also have a big impact on perceived site performance. Gathering measurements that account for these variables is difficult to do with local testing, but fortunately there are many services that can supply performance measurements using globally distributed testing servers, such as Gomez. In fact, Gomez offers a free instant testing tool you can use to measure your site performance as experienced by a computer in New York.

Performance testing does not require simulating load, or the process of testing your site under the simulated condition of many people hitting it at once. When you introduce load, you begin to test the scalability of a website and not the "pure" performance. Scalability tests are important, but when your focus is strictly improving site performance, load testing should not be used when collecting measurements.

How Do You Improve Performance?
Generally speaking, there are two key ways to improve performance in a website:

1. Reduce the number of bits that must be downloaded to load a page
2. Reduce the number of HTTP requests a page requires to load

If you can optimize these two factors, your site performance will improve.

Save the Tubes: Reducing Bits
One of the easiest ways to improve site performance is to reduce the number of bits your users must download to load pages. Fundamentally, all web pages require users to download bits from a server (in the form of HTML, CSS, JavaScript, images, etc.) that are then processed by the browser and ultimately displayed to the user in the form of your page. Reducing those bits reduces the time your users must wait to view your page.

There are several easy techniques you can use to begin reducing the bytes your users must download and improve page load times:

1. Compress HTTP Traffic
When a user requests an ASP.NET page, much of what the server returns is "text" data - HTML, CSS, and JavaScript. This type of data compresses very well, so applying compression on the server before the data is transmitted to a user's browser can significantly reduce the number of bytes that must be sent over the Internet "tubes." When the compressed data arrives at the user's computer, browsers have the built-in ability to decompress the received info and display it to the user.

The beauty of this technique is that it is extremely transparent. In most cases, you can apply HTTP compression to your site without making any changes to your code. The latest version of Microsoft's IIS web server provides built-in support for applying HTTP compression to basic communication between a web server and a browser, and third-party tools can be easily added to ASP.NET websites to compress "advanced" asynchronous AJAX and Web Service data (data which IIS7 does not compress).

2. Compress ViewState
Related to compressing HTTP traffic - at least in ASP.NET websites - is compressing ViewState. Many ASP.NET developers have a love-hate relationship with Microsoft's helpful "state manager" for the web, but regardless of your feelings, ViewState is something that must be managed. Even when ViewState is disabled in an ASP.NET WebForms application, ControlState, which cannot be disabled, can still fill the ViewState hidden field with data.

One way to reduce the impact of ViewState on your page is to compress it. By default, the ugly value stored in the ViewState field is serialized, but it is not compressed. There are methods you can override, though, that make it easy to compress and decompress ViewState on the fly. For example, with a few lines of code you can override the SavePageStateToPersistenceMedium page method and change the way ViewState is saved:

protected override void SavePageStateToPersistenceMedium(object state)
{
ObjectStateFormatter osf = new ObjectStateFormatter();
string viewStateStr = osf.Serialize(state);

byte[] bytes = System.Convert.FromBase64String(viewStateStr);

bytes = ViewStateCompressor.Compress(bytes);
string vStateStr = System.Convert.ToBase64String(bytes);
ClientScript.RegisterHiddenField("__VSTATE", vStateStr);
}

The process is simply inversed when ViewState is read on a page PostBack. This example also makes use of a "ViewStateCompressor" class, which is a simple class that provides your GZip compression and decompression logic. There are tools from third-party providers, such as Telerik's RadCompression, that also enable you to apply compression to ViewState without writing any code or making any changes to your pages.

Using ViewState compression in conjunction with HTTP compression is also a good idea, especially if you have a large amount of ViewState. While a server applies HTTP compression to the data it sends to a browser, a browser does not compress data sent back to the server when a page POSTs back. That means uncompressed ViewState must be uploaded by your users when posting a page. If you use ViewState compression, though, users benefit from this compression on both the initial page load and during POSTs back to the server.

3. Reduce HTML
Less markup on your page results in less data that your users must download, which ultimately results in a faster page load. Before you write this off as being too obvious, think about the ways you may be "overusing" HTML today. A common problem among web developers, and even among some ASP.NET UI components, is using HTML tables and in-line styles to define UI elements. Take, for example, the HTML produced by the default menu control available with ASP.NET (simplified slightly for clarity):

<table cellpadding="0" cellspacing="0" border="0">
<tr><td>
<table cellpadding="0" cellspacing="0" border="0" width="100%">
<tr><td style="white-space:nowrap;width:100%;">Book 0</td></tr>
</table>
</td></tr>
</table>

This code uses nested HTML tables to produce the menu's layout, which is a "heavy" use of HTML. A better solution, and a way to reduce the HTML on your page, is to use semantic HTML. Semantic HTML is markup that accurately describes its content. For example, a TABLE tag should contain tabular data. A UL tag should contain a list of items. Leveraging semantic HTML in combination with the power of CSS makes it possible to significantly reduce a page's HTML. A semantic rendering of our previous example reduces the required markup by a staggering 83%:

<ul class="menu">
<li>Book 0</li>
</ul>

Meanwhile, you can further reduce the bits your users are downloading by "minifying" your CSS and JavaScript. Minifying is similar to compression, but it does involve making changes to your code (usually done as part of a build process). When you minify JavaScript and CSS, all unnecessary characters and comments are removed, producing files that are very cryptic, but very small. Tools like YUI Compressor and JSMin are popular choices for JavaScript minification, and according to Yahoo minification reduces JavaScript size 21 percent on average (an additional 5 percent if you're already using HTTP compression). Like HTTP compression, minification is a transparent process that is easy to apply to existing code without introducing unexpected bugs.

4. Use Client-Side Rendering
This technique is different from the others covered up to this point and it requires a more fundamental change in your approach to web development. Where compression and minification are relatively transparent and easy to apply to existing code, transitioning from pages that render on the server to pages that can render in the browser requires new development habits and tools. Adopting these methodologies, though, is critical to making your standards-based web applications feel as responsive as desktop or RIA applications.

The general change in approach is this: rather than rendering a page's HTML on the server and then sending all of the data and all of the HTML over the wire to a client, instead you only send data over the wire (usually in JavaScript Object Notation, or JSON) and then use JavaScript in the browser to build your HTML layout. Where previous techniques we examined show you how to reduce the HTML sent over the wire, this technique eliminates it.

Adopting this approach without the assistance of any tools is very challenging, so developers usually leverage third-party tools or open source frameworks, such as jQuery, to assist with the processing of JSON on the client. With the proper assistance, developers can move away from the heavy PostBack model traditionally found in ASP.NET WebForms applications and begin leveraging web services and JSON to produce lightning-fast web experiences. The next version of ASP.NET will also provide support for client-side controls, making it easier than ever to completely remove HTML from client/server communication.

This approach is not without its caveats. Since JavaScript is required to display client-side controls, search engine crawlers cannot see content rendered on a page in this way. It's important to detect the capabilities of the client accessing your site and ensure the proper rendering technique is used.