What is RadCompression?
Simply put, RadCompression is a HttpModule that is shipped with the Telerik UI for ASP.NET AJAX and 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
It simply reduces the number of bits that are 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).
RadCompression is designed based on other HTTP
compression tools, such as the built-in HTTP Compression in IIS7 and higher versions.
By adding RadCompression
to your project, you start compressing your AJAX and Web Service responses.
will automatically detect and compress requests that expect these content response types
(as found in the HTTP request's "ContentType" header or "AcceptsTypes" header):
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 (most modern browsers do) and RadCompression
is enabled, all content of this type will be compressed. The one exception is IE6, which does not support
this compression well, so RadCompression will automatically ignore requests coming from
How is RadCompression enabled?
Enabling RadCompression could not be easier. It is a simple matter of adding a HttpModule registration to the site's
web.config. Specifically, you need the following:
<add name="RadCompression" type="Telerik.Web.UI.RadCompression" />
<add name="RadCompression" type="Telerik.Web.UI.RadCompression" />
By default the RadCompression module will compress AJAX requests only (with the content type headers specified above), however you can
enable compression for regular postbacks as well setting the enablePostbackCompression property to
true (its default value is false, see web.config section below).You also have the option to disable the compression for particular pages
if necessary. To do that use the RadCompressionSettings attribute of the page in question:
Another aspect of the RadCompression model allows you to exclude particular request handlers through the RadCompression web.config
configuration settings. Here is an example how this can be done (note the matchExact attribute which determines
whether the rule will be forced for the specified path only or globally for the entire web site/web application project):
<section name="radCompression" type="Telerik.Web.UI.RadCompressionConfigurationSection, Telerik.Web.UI, PublicKeyToken=121fae
8165ba3d4" allowDefinition="MachineToApplication" requirePermission="false"/>
<add handlerPath="grid/defaultcs.aspx" matchExact="true"/>
<add handlerPath="defaultvb.aspx" matchExact="false"/>
<add handlerPath="MyFolder/" matchExact="false"/>
When using IIS dynamic compression enabling RadCompression is not required as this will result in double compression of the response.
When you enable the RadCompression module, you get the entire response compressed including the ViewState. However, you also have the option
to turn on only ViewState compression and store it either in a hidden field, or in the Session (to pass and retrieve it from there on form submits), without
compressing the rest of the response. For this
purpose you can use additional page adapters which override the default page adapter for viewstate storage. To enable viewstate compression
you can register these RadCompression controlAdapters using BrowserFile.browser file
in App_Browsers folder of your web site/project. Here is how to register a hidden field which will be used
as a container for the compressed page viewstate:
<adapter controlType="System.Web.UI.Page" adapterType="Telerik.Web.UI.RadHiddenFieldPageStateCompression" />
To use this adapter you do not need to enable RadCompression module through the web.config file as described above.
RadHiddenFieldPageStateCompression might be used separately from the RadCompression module in cases where only viewstate compression is needed.
Using both at the same time could result in compressing the ViewState twice.
You can also store the compressed ViewState in the Session:
<adapter controlType="System.Web.UI.Page" adapterType="Telerik.Web.UI.RadSessionPageStateCompression" />
In this case enabling RadCompression at the same time would be fine, as when the compressed ViewState is saved in Session, it is not included in the response, so
the RadCompression module does not compress it.
RadCompression and SessionPageState
Due to the fact that RadCompression module takes advantage of the
ASP.NET's SessionPageStatePersister there are some scenarios where you may need to fine-tune its settings:
ControlState - by default, the SessionPageStatePersister doesn't add
the ControlState to the Session so you may need to add it manually:
Page history - in applications where you have a lot of popup windows, it is important to increase the
amount of the pages that are persisted in the Session. The default value of the history size is 9.
<sessionPageState historySize="15" />
When IIS dynamic compression is enabled the ViewState will be automatically compressed even if the RadCompression module is not enabled.
How to enable compression for regular postbacks?
You can enable the postback compression by setting the enablePostbackCompression property of the
RadCompression module to true (the default value is false). This can be done at application level
in the following manner:
<section name="radCompression" type="Telerik.Web.UI.RadCompressionConfigurationSection, Telerik.Web.UI, PublicKeyToken=121fae78165ba3d4" allowDefinition="MachineToApplication" requirePermission="false"/>
Note that setting the same attribute at page level will override the web.config settings because it will be treated with
Here are some of the known issues you can face when using RadCompression.
When RadCompression is enabled and you are using .NET 4.0 or .NET 4.5, event handlers might not be raised in a default document
in IIS 7 and higher versions Integrated Mode.
Solution: This problem is caused by a breaking change in .NET 4.0 described
here. To workaround it one can set preCondition="managedHandler" for the
RadCompression module. You may also need to remove the runAllManagedModulesForAllRequests setting from
your web.config if you have it (or set it to false).
RadControls bound to a WCF services do not work In Classic AppPool scenarios with Windows authentication enabled.
Solution: Try removing RadCompression from the HttpModules section of the web.config. We have found out that on some machines RadCompression halts the WCF responses, effectively breaking the pages that consume the services.
What is the benefit?
You can see the results from eight unique tests made by our evangelist Todd Anglin in the
following blog post and in
this blog post concerning the usage of page adapters.
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 do not have much to lose. In a quick word:
RadCompression is an easy way to reduce the bytes sent over the wire for XHR operations.