Optimization Tips: Testing Page Performance

Welcome back to my new series covering optimization tips for the Telerik RadControls for ASP.NET AJAX. The last time we visited, I showed you how you can reduce your initial page load times 30%, on average, by simply adding the RadScriptManager and RadStyleSheetManager to your application's pages. In this installment, we'll look at two follow-up issues: how does the web.config debug property affect page load performance and how much slower is Cassini than IIS.

When I conducted the tests for the first installment, I made sure "compilation debug" was set to false in my web.config and I used IIS to get pretty accurate results (I add the qualification because I didn't run the tests on a high performance web server, but you can expect that would only improve the absolute values). What would have happened, though, if I deployed my test website and forgot to set the debug property to false? Or even more serious, if I had used the Visual Studio Web Server (Cassini) instead of IIS for my tests, how would that have impacted my perception of page performance? That's what we'll quantify in part two. The results may or may not surprise you, but they'll certainly prove to you why it's important to save your impressions of page performance until a site is running in IIS with "debug=false" in the web.config.

Simple property, big impact
One of the easiest ways to tank the performance of your fancy ASP.NET AJAX website is to forget to set the compilation debug property in the web.config to false. This property has been used by ASP.NET for years to control debug and release builds, but the introduction of ASP.NET AJAX and it's richer client-side programming environment has added a serious client-side page load penalty for sites running in debug mode. Specifically, when ASP.NET AJAX detects that a site is running in debug mode, it loads a special debug version of the ASP.NET AJAX client libraries tuned for maximum debugging- not performance.

This feature of the ASP.NET AJAX framework is great for development because it makes it much easier to debug client-side code without impacting the performance of "release" libraries. And when the time comes to move your application to production, a simple property change will let ASP.NET AJAX know that it should deploy the tuned-for-performance release versions of the client libraries and turn-off the excessive debugging. That is, of course, if you remember to change the property.

The compilation debug property is located in your application's web.config file within the system.web block. It is a boolean property that defaults to false, but if you develop with Visual Studio, it is very easy to set this property to true without thinking. If you've been developing with ASP.NET for any amount of time, I'm fairly certain you've seen this setting, but you may not fully understand how substantial the impact is of not setting this property correctly.

To answer that question, I turned to the same sample application we introduced in part one of this series. It consists of a page with RadGrid, RadTreeview, RadMenu, RadSplitter, RadAjax, and (for these tests) RadScriptManager and RadStyleSheetManager. I tested page load times using IIS and IE7/8 and FF2/3, loading the page 6 times in each browser: 3 loads with a primed cache, 3 unprimed. The key difference for these tests, though, is that I set debug in the web.config to true.

In the above chart, the "Unprimed" and "Primed" series are the same values from part one's page load tests with the Rad Managers. They serve as our baseline for the new tests. Next to the old results, you see "Unprimed+Debug" and "Primed+Debug." These series show the difference in page load times when you simply forget to set "debug" to false. From these results we learn a few things:

• On average, across browsers, debug = true makes initial page loads 27% slower
• On average, cached page loads are 23% slower
• Firefox is again the poor performer
• Initial page loads are almost 40% slower in debug mode with IIS!

The obvious point: don't deploy applications with debug still set to true! You can hurt application page load time by 25% if you miss this.

Convenient and slow
Do you remember when Visual Studio didn't have a web server built-in? I know it's been a while now, but there was a day when every web site developed in VS had to be manually setup in IIS just to see it run. Thankfully, those days are behind us and the Visual Studio Web Sever (originally Cassini) has made the process of quickly building and testing web sites as easy as a single keystroke.

While Cassini is great for rapid application development, it's far, far from being the robust ASP.NET server that is IIS. I think all ASP.NET web developers understand this fact casually (we'd never try to run an ASP.NET website in production on Cassini- if it were even possible), but I don't think the difference between Cassini and IIS performance is well understood- especially in the context of page load time with ASP.NET AJAX. To make that difference clear, I ran another batch of tests, this time testing page load times in Cassini, still with debug set to true.
As with the debug chart, this chart compares our baseline page load times to page load times for our test page (in debug mode) served by Cassini. The results are pretty dramatic:

• Firefox- even the new and improved Firefox 3- shot page load times through the roof
• On an unprimed cache, pages load 91% slower (FF2 & 3 avg.)!
• On primed, pages still loaded 72% slower
• Across all browsers, pages loaded on average 50% slower
• Excluding Firefox, pages loaded an average of 20% slower in IE7 & 8

So what? What are supposed to do about a slow development server? Nothing, really. The point here is that you should never make judgments about how long it takes your page to load if you're using Visual Studio's Web Server. When pages are in debug mode (which they usually are in Cassini), your page load time could take more than twice as long in development than it actually will in release mode served by IIS.

Optimization Tip Summary
This tip doesn't really provide you with anything you can specifically do to the RadControls to make them load faster, but it does drive home important points about measuring the performance of your pages that use the RadControls for ASP.NET AJAX. Now that you've seen the actual impact of compilation debug and the Cassini web server on page load time, you know that they can have a dramatically terrible impact on your page's performance and thus on your perception of the RadControls. Always make sure you test performance using IIS with pages running in release mode to get an accurate picture of how your pages are performing.

If you practice this tip, combined with the Rad Managers talked about in part one, and future optimization tips in this series, you'll be guaranteed to see page load times that make you smile- not scream!