Optimization Tips: RadCompression Module

[Cross-post of content on my Telerik.com blog, for your reading convenience.]

Welcome back to the ongoing Optimization Tips series. It's been a while since the last installment, so it's high-time we took a look at more tips and tricks for optimizing your Telerik-powered web applications. In this the seventh article in this series, we'll take a look at Telerik's brand new RadCompression HttpModule and try to gain a deep understanding of how this tool can help improve application performance. Some of the concepts in this article build on things we've discussed in previous installments, so I encourage you to read the earlier articles before reading this if you have not already done so. Let's get started.

WHAT IS RADCOMPRESSION?

Simply put, RadCompression is a HttpModule that ships with the RadControls for ASP.NET AJAX (Q3 2008 SP2 and later) that is designed to automatically compress your AJAX and Web Service responses. In other words, RadCompression will intercept the bits that your server is sending back to a browser (or Silverlight-client, for that matter) and compress them. Once the compressed bits reach the browser, standard browser technology takes-over and decompresses the response so your application can work with it normally. The compression process is completely transparent to your client-side code (JavaScript or Silverlight) and your server-side code. It simply reduces the number of bits that must be sent over the wire (from your server to your client) and thus- in theory- improves your page performance by reducing the TTLB (time to last byte).

Continue reading RadCompression Optimization Tip

WHAT RADCOMPRESSION IS NOT

RadCompression is not designed to be a complete replacement for other HTTP compression tools, such as the built-in HTTP Compression in IIS 7. Instead, it is designed to work with those existing tools to cover scenarios they usually miss- namely the compression of bits moving back and forth in AJAX (and now Silverlight) applications. If you have HTTP Compression enabled in IIS7, you'll discover that it does not compress your AJAX and Web Service responses; it only compresses the initial bits sent to the browser when the page is requested. By adding RadCompression to your project, you cover those gaps and start compressing your XHR (XmlHttpRequest - i.e. the "X" in AJAX).

So, if RadCompression does not cover all HTTP traffic, what does it cover? Quite simply, RadCompression will automatically detect and compress requests that expect these content response types (as found in the HTTP request's "ContentType" header or "AcceptsTypes" header):

• application/x-www-form-urlencoded
• application/json
• application/xml
• application/atom+xml

These types generally reflect the content types returned by AJAX Web Services, ADO.NET Data Services, and AJAX UpdatePanel responses, though there certainly are other scenarios that return these content types (such as a typical RSS feed). If a browser supports compression (and most modern browsers do), and RadCompression is enabled, all content of this type will be compressed. The one exception is IE6, which does not well support this compression, so RadCompression will automatically ignore requests coming from IE6 clients.

HOW DO YOU ENABLE RADCOMPRESSION?

Enabling RadCompression really couldn't be easier. It's a simple matter of adding a HttpModule registration to your site's web.config. Specifically, you need the following:

XML (Web.Config)

<httpModules>
...
<!-- Add this line exactly as is - the name value is important -->
<add name="RadCompression" type="Telerik.Web.UI.RadCompression" />
</httpModules>
<!-- If you're using IIS7, then add this, too-->
<system.webServer>
  <modules>
    ...
    <add name="RadCompression" type="Telerik.Web.UI.RadCompression" />
  </modules>
...

With that single line of configuration (or two lines if you're using IIS7 Integrated Pipeline), RadCompression is ready to work. You don't need to make any additional code or configuration changes. The compression module will automatically look for content that matches the conditions mentioned above and compress it. Remember that HttpModules, unlike HttpHandlers, touch every request processed by ASP.NET, so you don't have to do anything to your pages or services to make the compression work. All compression is handled by the module. All decompression is handled by the browser.

WHAT IS THE BENEFIT?

Time to get down to the brass tacks. Does RadCompression really help improve your application's performance? As you know, in the Optimization Series, we've been testing different optimization techniques and their effect on page load time. It's crude, but it gives you a relative idea of how the technique can improve your application's performance. For RadCompression, I ran eight unique tests, executing each six times to collect a reliable sample set. The tests are composed of two distinct scenarios:

1. UpdatePanel Updates: In this scenario, there is a page with a RadGrid, bound server-side during the NeedsDataSource RadGrid event, with a RadAjaxManager on the page to "ajaxify" all Grid operations.
2. Client-binding Updates: In this scenario, there is a page with a RadGrid that is declaratively bound to a ADO.NET Data Service (which, for the unfamiliar, is essentially a fancy WCF web service). The RadGrid fetches data via the service and initializes in the browser and uses the web service for all operations, such as paging.

For both scenarios, the data layer is a simple LinqToSql model using the AdventureWorks database. Both grids are bound to all Employees in the AdventureWorks data store, so the scenarios should be equal except for the way they handle initial data binding and binding for operations like paging. For each scenario, we'll test the following, measuring bytes sent during the request, bytes sent in the response, total requests, and page load time:

• Initial page load
• Paging the RadGrid with RadCompression disabled
• Paging the RadGrid with RadCompression enabled
• Loading and paging the RadGrid with RadCompression + the RadManagers (RadScriptManager, RadStyleSheetManager)

These tests will show us the relative impact of adding RadCompression to a site. Let's take a look at the results:

Average Bytes Received

This chart reveals some interesting facts. First, we see that choosing to use UpdatePanels (and server-side binding) or client-side binding does not significantly initial page load size. In fact, it takes a few more bytes to start with client-side binding (though we see when the RadManagers are used those bytes compress better). The real benefit of the client-side binding is revealed in the RadGrid paging operations, where the bytes received are reduced by 62% (on average). When we add the RadCompression HttpModule, we see improvement in both scenarios paging scenarios. With UpdatePanels and "traditional" AJAX, bytes sent over the wire are reduced by about 68% with RadCompression enabled, and by about 86% with client-side binding. So right away we see that RadCompression has a significant impact on reducing traffic for async operations like paging in RadGrid.

Average Page Load Time

The load time results can be a bit confusing at first. They are not nearly as dramatic as the reduction in bytes received, so you have to look close to understand what's happening. First of all, we can see that all operations- including the initial page load- are happening in less than one second. In fact, all of the paging operations are happening in about 1/10 of one second! That means the localhost environment makes it hard to see the impact of the compressed bytes on page load time while paging a RadGrid. You can see, of course, that the RadManagers help reduce the initial page load time by about 25%, but the RadCompression module has a negligible impact on the RadGrid paging load time. The take away: for sites deployed to a local network (i.e. intranet sites), you really don't need to worry about performance optimizations at the level RadCompression provides. The latency is low enough and the bandwidth high-enough that you won't see a significant impact on page load performance. For remote sites, though, the delta between load time with and without RadCompression should be much more obvious (thanks to the time required to transfer 75% more bytes over the wire).

OPTIMIZATION TIP SUMMARY

When it comes to RadCompression, the impact it has on your site just depends on where your users are located. If you have a site that is deployed over the web, where latency and connection speeds are unpredictable, reducing the bytes you send over the wire is an easy way to improve your site's performance. And since RadCompression can literally be implemented with a single change to your config file, you really don't have much to lose. In a quick word:

RadCompression is an easy way to reduce the bytes sent over the wire for XHR operations.

Hopefully you'll enjoy this new tool in your Telerik toolbox. Whether you use them or not, Telerik is working hard to give you all of the tools you need to optimize your websites with very little work. When combined correctly for the right sites, we believe we can enable you to not only to build sites quickly, but with measurable top performance.