From the Desk of Chief Evangelist for Telerik

Todd Anglin

Subscribe to Todd Anglin: eMailAlertsEmail Alerts
Get Todd Anglin via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: RIA Developer's Journal, eCommerce Journal, Internet Marketing, IT Strategy, Web Analytics, Social Commerce, Microsoft Developer


Practical Approaches for Optimizing Website Performance

Improve performance and responsiveness

Ask Less: Reducing Requests
What is the primary performance bottleneck in browsers today? Browser request limits. With dial-up connections a thing of the past for most users and PCs more powerful than ever before, waiting on the browser to request and download all the "pieces" of your page is usually what requires the most time for modern websites. According to Yahoo's Exceptional Performance Team, 80 to 90 percent of end-user response time is spent waiting for these pieces.

Per the HTTP/1.1 specification, most browsers limit parallel requests to two per hostname, and six total (for all tabs and hostnames). Think about that. Assuming you're not using any of the techniques discussed later, that means every image, every JavaScript file, and every CSS file can only be downloaded two at a time. The limits were originally created in the days of weaker computers and slower connections to prevent systems from being overloaded, but today they represent a huge barrier to site performance.

Here are some techniques you can implement in your site that will not only reduce requests, but also "trick" browsers in to allowing you to use more than two parallel requests.

CSS Sprites
Sprites find their roots in early video games, where processor-strapped developers needed a technique to optimize performance. As processing power improved, video games had less use for this optimization technique, but web developers now leverage it as a way to reduce requests to the server.

Put simply, CSS sprites are essentially a collection of images that have been combined into a single, larger image file. The images can be several states (such as "normal" and "mouse over") of the same image, a collection of unique images (such as toolbar icons), or a combination of both. The "magic" of CSS sprites is the use of CSS background positioning to only display the portion of the large, single image file where a smaller image should be shown.

The main advantage of sprites is that they significantly reduce requests to the server. Think about all of the images your website downloads today when it loads. Each of those images represents a request to the server, and with the default two-request limit, images can quickly clog the request queue. By using sprites, you could in theory replace all images in your site with a single image file, though this is not the way sprites are commonly used. While the resulting sprites are larger files, modern computers with broadband connections are much better at downloading fewer larger files than hundreds of small files, due to the overhead and latency of processing HTTP GETs.

The advantages of CSS sprites are clear, but they can be hard to create from scratch. Several online tools can help you transform individual images into sprites, and a quick search for "css sprite generator" should help you discover the popular options. Further, when evaluating UI components to use in your ASP.NET websites, make sure the controls use CSS sprites in their own rendering.

Script Combining
If CSS sprites are used to combine images, then script combining is the related technique for combining CSS and JavaScript files. The main advantage of script combining is the same as CSS sprites: fewer files to download, which means fewer requests and a faster loading page. Script combining can be done manually, but there are many tools today for ASP.NET developers that will do JavaScript and CSS file combining on the fly, eliminating the need to constantly re-create combined versions of your resource files as you modify them.

With .NET 3.5 SP1, the ScriptManager control that ships with ASP.NET AJAX can do automatic JavaScript combining. To leverage that feature, use the new CompositeScript block, like this:

<asp:ScriptManager runat="server" ID="ScriptManager1">
<asp:ScriptReference Name="MicrosoftAjax.js" />
<asp:ScriptReference Name="MicrosoftAjaxWebForms.js" />

The ScriptManager supports combining both scripts found in the ASP.NET AJAX assemblies and your own external scripts. By default, ASP.NET AJAX makes 11 separate requests for framework scripts when you use a ScriptManager control, so using combining for these scripts alone will shave 10 requests off your initial page load.

Varying Hostnames (and CDNs)
This technique will not help you reduce requests, but it will enable you to work around the browsers default two-request limit and potentially allow your page to download up to four times as many files at one time. The solution is rooted in the fact that a browser enforces the two-request limit based on hostname, such as "www.yoursite.com." To the browser, hostnames like "www.yoursite.com," "images.yoursite.com," and "images2.yoursite.com" are all unique and each can process two requests at once when your page loads. Fully leveraged, you can effectively quadruple your site's allowed bandwidth.

When you vary hostnames, you can have the resource URLs point to physically separate locations, or you can have them all route to the same location via DNS routing. The browser does not check to ensure the each hostname has a unique IP address. You can also use something called a Content Delivery Network (CDN) to further improve performance by placing resources, such as videos and images, geographically closer to your users, thus reducing latency and improving download performance. Since a CDN also lives on a separate hostname from your site, it inherently helps work around the browser request limit, too.

Load JavaScript Last (When You Can)
This last technique also does not help you reduce requests, nor does it help you work around the browser request limit, but it does help your page process requests as quickly as possible. The problem is that browsers will block additional requests if JavaScript is being downloaded, regardless of browser request limits and hostnames. Browsers do this because the JavaScript being downloaded could have an effect on page layout, and waiting prevents unnecessary and expensive redraws of the page as it loads.

Moving JavaScript to the bottom of your page enables all other requests to process quickly, which will make your page appear to load more quickly. The browser will begin rendering faster if it's not waiting on all of your JavaScript to load at the top of your page.

Of course, not all scripts can be moved to the bottom of a page. If the script is a library, such as jQuery, that is required for other components on the page to render, it must be loaded early in the page lifecycle. As a general rule of thumb, any script that is not involved in manipulating the initial layout of your page can (and should) be placed at the bottom of your page.

Measuring Tips for ASP.NET Developers
Now that you're armed with an arsenal of new techniques to apply to your websites to begin improving performance, you're likely to want to gather some measurements. We've already discussed the general approach for measuring performance, but there are some specific "tips and tricks" for ASP.NET developers that can help you gather accurate results:

  • Never use the integrated Visual Studio web server ("Cassini")

It may seem obvious that you shouldn't use Cassini to gather performance data for your site, but during active development with Visual Studio it can be easy to forget the impact this lightweight web server has on performance. In local tests conducted on a simple ASP.NET page, pages served by Cassini on average take 20 percent to 50 percent longer to load than IIS. Before you spend days trying to get a page to load in less than a second in your development environment, make sure you test the page in a real web server and measure real performance.

  • Always set "debug=false" in the compile section of web.config

Perhaps similarly obvious to not testing performance with Cassini, most ASP.NET developers know that leaving "debug=false" in web.config negatively impacts performance. But do you know how much it impacts load time performance? In local tests, the simple act of setting "debug=false" improves average page load time by 27 percent.

  • Differentiate between "primed" and "unprimed" browser cache

Finally, it's important to make sure your tests differentiate between a "primed" and "unprimed" browser cache. Many of the performance bottlenecks examined in this article are hard to observe on a "primed" cache, because the browser will load images, scripts, and resources from a local cache instead of trying to pull the data from the server. Clearly, most users will benefit from this caching after their initial visit to your site, so it's important that you measure both primed and unprimed scenarios to understand how the performance experience differs.

Many of the techniques outlined in this article are easy to implement. Spending a few hours testing these techniques and measuring the results will help most modern, interactive websites improve performance and responsiveness. Optimizing performance can be a challenging task, but armed with these eight techniques AJAX ASP.NET developers can easily begin the process.


More Stories By Todd Anglin

Todd Anglin is Chief Evangelist for Telerik, a leading vendor of development, automated testing, and team productivity tools, as well as UI components for Microsoft .NET. Before joining Telerik, he worked for a large Fortune 200 financial services company IT shop where he learned the way of the “Enterprise” – big budgets, big projects, legacy systems, and incessant measurement. He now leverages this Enterprise experience to help Telerik make tools that make the lives of all developers as easy as possible. Todd is an active author and speaker in the .NET community, focusing on web development technologies, a Microsoft MVP, founder and President of the North Houston .NET Users Group, and an O'Reilly author.

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
JonoP 08/27/09 08:30:00 PM EDT

Great article Todd. I would have found it especially useful to hear your opinion on some of the performance optimization software options out there that can automate the good practice that you mentioned - we're trialling one at the moment (aptimize) and your opinion would be valuable. In my experience techniques are great but their application can be patchy, we're looking for something that we can put on and go and get a consistent level of optimization.