ASP.NET Performance Improvements in DevExpress 2009 volume 2

20 July 2009

DevExpress ASP.NET Performance: Speed with custom HTTP HandlerI'm thrilled to announce the new performance enhancements of the upcoming DevExpress ASP.NET controls. Our ASP.NET controls just got a major performance boost from a few changes -- in fact, several of these were prompted by your requests.

Read on for more details…

New HTTP Handler for Resources

This is the biggest reason for the performance boost. Instead of the using standard HTTP Resource handler provided by ASP.NET, to get resources from the server, we've implemented our own custom HTTP handler which increases performance.

Basically, the DevExpress HTTP handler changes how the compressed scripts and CSS files are transmitted from the web server to your browser. This makes round-trips to the server much faster. And it also reduces the HTML code size by providing shorter links for the resource URLs!

Another performance advantage comes from the result of smarter script transmission to the client-side. Previously, script files were batched together and sent to the client even if all the files weren’t necessary. With the new custom HTTP handler:

  1. Our ASP.NET controls can analyze which scripts are necessary for each request
  2. Join those scripts dynamically into a single batch
  3. And send them to the client-side

Your websites will get an instant boost by using the DXperience ASP.NET 2009 volume 2 release.

How fast?

We ran a performance comparison between the 2009 volume 1 and the upcoming 2009 volume 2 releases. Using a customer reported scenario, we created one ASPX test page and added one ASPxGridView, two ASPxButtons, three ASPxComboBoxes  and three ASPxCheckBoxes.

Here’s the summary of the test results:

  1. The new resource handler compresses script- and CSS-files. Since these are text files, the compression for them is very good (about 5 times, i.e. the compressed size is 20% of the original size). Check out the Fiddler results below for more information.
  2. Because the new resource/ HTTP handler in the 2009 volume 2 release makes resource URLs shorter - it reduced the overall HTML render size of the test page by about 12-13%. Here’s a sample of the difference:

    - 2009 volume 1 (standard handler - long URLs):
    Code Snippet
    1. <head><link rel="stylesheet" type="text/css" href="/grid91/WebResource.axd?d=6pSNzQ1UD-xbX4brCyMRS5Aety-hEChDGMAZMfvfsvLyvX8p0-PWSTlzWq8GzSpz4hemwcf0CWYmNvrCkeu_3Q2&amp;t=633784297566166839" />
    2. < link rel="stylesheet" type="text/css" href="/grid91/WebResource.axd?d=6pSNzQ1UD-xbX4brCyMRS9SgRpCgVZy9dht7IfwJ8wGam6IzSaAyQWZHZi3WhzChkO6yhP_zVSMDMu0nVhHKcKs7-MXEoaluDT3hQ7Ch9Fo1&amp;t=633784297644423039" />
    3. < link rel="stylesheet" type="text/css" href="/grid91/WebResource.axd?d=6pSNzQ1UD-xbX4brCyMRS0bFPfhKDiNLdRIXGSYh0yAICuinqxp3lSp2F8u9TT_vta4GuI5olw_Gsex686sFbRsMqUUqUpyNJqrzG7tTpe41&amp;t=633784297596469639" />

    - 2009 vol 2 (our resource handler - short URLs):
    Code Snippet
    1. <head><link rel="stylesheet" type="text/css" href="/grid92/DXR.axd?r=2_2,3_22,1_69" />

    This feature is optional so to activate it, add the following key to your web.config’s appSetting section (DXEnableResourceMerging):

    Code Snippet
    1.     <appSettings>
    2.         < add key="DXEnableResourceMerging" value="True" />
    3.     </ appSettings>

  3. Another new performance feature is the ‘combine all scripts in one file (from different assemblies) and merge all CSS-files in one file’. This feature helps reduce the number of requests to the server.

    Script-files (and CSS) are compressed by the server before posting to the client. The reduced size is about 20% of original size (i.e., reducing it by 4-5 times the original size).

    To test, we launched the Fiddler2 tool and got the following impressive results:

    2009 volume 1

    Request Count: 31
    Bytes Sent: 14,561
    Bytes Received: 788,598
    Sequence (clock) time: 00:00:00.5935258
    text/ Java Script: 644,219
    application/x- Java Script: 20,794
    US West Coast (DSL - 30KB/sec)  
    Round trip cost: 3,10s
    Elapsed Time: 29,10s


    2009 volume 2

    Request Count: 16
    Bytes Sent: 5,820
    Bytes Received: 220,217
    Sequence (clock) time: 00:00:00.2967629
    text / Java Script: 130,910
    application / x- Java Script: 20,794
    US West Coast (DSL - 30KB/sec)  
    Round trip cost: 1,60s
    Elapsed Time: 8,60s

    Traffic is reduced by about 3.6 times (220,217 KB for 2009 volume 2 VS 788,598 KB for 2009 volume 1).

    Scripts are reduced by about 5 times their original size (130,910 KB for 2009 volume 2 VS 644,219 KB for 2009 volume 1).

The reduced amount of traffic means faster page loads for your websites (especially for slow connections). These enhancements are part of our dedication to bring you features, quality and performance in the DXperience Subscription.

DXperience? What's That?

DXperience is the .NET developer's secret weapon. Get full access to a complete suite of professional components that let you instantly drop in new features, designer styles and fast performance for your applications. Try a fully-functional version of DXperience for free now:

Jens Fudickar [DX-Squad]

It will be interesting to see these features in the new DevExpress homepage and support page.

Both are not the fastest now

Kind regards


20 July, 2009
Boris Bosnjak

A remarkable optimization!

20 July, 2009
Dallas Sehlhorst 1

Mehul- congrats to you and your team for implementing this!  Any plans on using JSON for the updates instead of passing all that extra HTML around?  We know you guys can do it!  Maybe semantic rendering too?  I see JQuery in your future...

20 July, 2009

I am always pleasantly surprised

20 July, 2009

Very cool stuff!

21 July, 2009
David Janecek

Yey! I was wondering about that .js file that was getting sent down to the browser for every request...

21 July, 2009
Geoff Davis


21 July, 2009
Roma R (DevExpress)

Hi Jens,

These features are used in a new version of our web site. It is going to be released in a month.

21 July, 2009
Chloe Anfield

Would I be correct in assuming that XAF web will also benefit from these performance enhancements ?

21 July, 2009
Martijn van IJperen

I want it :)

21 July, 2009

That's very impressive, indeed! :)

However, I hope you guys intend to do your own tags in web.config VERY SOON! Assembly-specific settings should be stored within their own config section. I highly dislike the idea of you using the generic AppSettings collection for it.

21 July, 2009

Can't wait for this...

21 July, 2009
Gary L Cox Jr [DX-Squad]

This is very cool, I love how it automatically bundles the CSS and Javascript into one file.  Smaller page sizes is always a ++

21 July, 2009

em...  about time, but great work all the same :-)


Isn't the server doing more work though?  Yes the data sent through the wire is less but if the server is doing more work to make it so, is there really any speed gain?

21 July, 2009
Matthew K

Has local caching support been considered for increasing performance?

21 July, 2009
Mehul Harry (DevExpress)


As Roman said, the new website uses these controls and it's FAST! Last iternaion I saw, loaded in about 2-3 seconds.

21 July, 2009
Mehul Harry (DevExpress)



Yes, jQuery is in the future, sort of. We'll be using it for the MVC grid. As for the JSON suggestion, our callbacks are not that heavy.

Also, there's some more perf enhancements planned for 2009 volume 3!

21 July, 2009
Mehul Harry (DevExpress)


Yes! Since the eXpress App Framework is based on the DevExpress controls.

21 July, 2009
Mehul Harry (DevExpress)

Hi Awake,


The server(cpu) vs bandwidth is easy to answer, imo. Process on the server to get the bandwidth down.

CPU processing power costs are cheaper compared to bandwidth costs. And it's much faster to process on the server and have less traffic as a benefit.

So yes, there is a speed gain since server will only take a few extra milliseconds to do the work. Besides, you can see the end result in the comparison. It's definitely worth it. Smile

21 July, 2009
Mehul Harry (DevExpress)


Hmm, not sure we'll do custom tags but please create a suggestion:

21 July, 2009
Mehul Harry (DevExpress)


No haven't considered that but you may want to create a suggestion with the proposed idea:

There is another feature planned for the 2009 volume 3 release that will increase performance. Stay tuned...

21 July, 2009
Hal Roseman

we have iis7 and dynamic compressiong is enabled and we see lot of perfomance benefits with compression.So my question was,if i add < add key="DXEnableResourceMerging" value="True" />  in web.config will this helpful with dynamic compression when enabled?

21 July, 2009
Sebastià Prat

Great! We appreciate it so much. Good work.

I don't understand why to use DXEnableResourceMerging setting?

How many people will not use it? Does it has any limitiation?


21 July, 2009
Mehul Harry (DevExpress)

Hi Robert,

Yes, you should since the resources will be merged and there should be less traffic and less requests.

21 July, 2009
Karl Rostock_2

Hi, i really like the changes/improvements i know you wont tell me but ill ask anyway, when will v2 be released we are now well into the 2nd quarter without even a Beta, im telling customers "Ohhhh ive got some new features for you they should be finsihed soon" and 4 weeks on still no sign :-(

22 July, 2009
Roma R (DevExpress)


Of course, all our resources are cached by the browser on the client side; by our code - on the server side. You can check this using the Fiddler tool.

If you press F5 in the browser when your page has been loaded, the browser will try to get resources from the server side  - in this case the server cache works; if you navigate to your page for the second and subsequent times, you won't see resource requests in the Fiddler tool - the client cache works in this case.

22 July, 2009
Roma R (DevExpress)


This happens because of caching.

For example, you have two pages. Page1 contains Script1, Script2 and Script3; Page2 - Script1, Script2.

The ResourceMerging feature is enabled.

First you navigate to Page1. The Script1_Script2_Script3 resource is loaded and cached.

Then you navigate to Page2. It has the Script1_Script2 resource and this resource isn't loaded. So, it has to be loaded.

The ResourceMerging feature is disabled.

Again you navigate to Page1. The Script1, Script2 and Script3 resources are loaded and cached.

Then you navigate to Page2. It has the Script1 and Script2 resources and these resources have been already loaded. So, they can be obtained from the cache.

Of course, if you navigate to a page for the second and subsequent times, the resources will be obtained from the cache.

So, if you have 1 or 2 pages in your site, it makes sense to enable this feature.

If you have 10 pages in your site and, for example, 7-8 pages are similar, it makes sense to enable this feature.

If you have 10 pages in your site and they are pretty different, most likely it doesn't make sense.

22 July, 2009


I truly hope you guys consider this, because to me it's one heck of a showstopper. :(

22 July, 2009
Aaron Smith

This is great news!

Does this by chance make it easier for you guys to implement controls for ASP.Net MVC?

22 July, 2009
Sebastià Prat


In this case:

"If you have 10 pages in your site and they are pretty different, most likely it doesn't make sense."

How much overhead of the webserver will represent having this feature enabled? Or of the client?

Thanks Roman R

22 July, 2009

We're just about to release v2009.2 and it would be a good idea to have an "accumulator"

20 August, 2009
The ASPx Blog - Mehul Harry's DevExpress Blog

Hang on to your seats, I’ve got more good news about the ASP.NET controls performance in the DXperience

4 September, 2009
DotNetBurner -

DotNetBurner - burning hot .net content

12 September, 2009
Ken Gliddon

what a little jem! thanks for sharing the information.

2 February, 2011
Will Stanley



It sort of feels like I am the last one to arrive at the party writing this. But I feel compelled to say how amazed and pleased I am with upgrading from 9.1.5 to 9.3.

Did a YSlow report before and after and the size of the javascript files fell to roughly 17-25% of their previous size and the HTML files fell to 22-42% of their previous sizes!!!! The CSS file sizes also fell (although one doubled in size, not sure why) to between 33-83% of their size.

This is just fantastic and my pages feel lightening fast. I look forward to see if my bounce rate falls and the number of actions per visitor rises. The monthly bandwidth on the site will also fall nicely, I was just on the cusp of having to buy more, so nice one!

PS I have a few other questions....

9 March, 2011
Mehul Harry (DevExpress)

Hi Will,

Thanks. I'll take a look at your forum thread.

9 March, 2011

Please login or register to post comments.