I've had a problem with customers complaining about the performance of a page using RadScheduler. To be fair, there are other controls besides a RadScheduler in the same page (RadMenu, RadToolbar and RadTreeView). Anyway, the page is heavy on data, and feels sluggish.
I did some benchmarking with YSlow and Chrome Speed Tracer. YSlow told me that my page was about 1MB in total size.
The problematic part is the generated HTML that has to be loaded every time. This is the text you see in the browser's "view source". Of the one megabyte, HTML took about 400KB. It contained:
- ViewState ~ 150KB
- Script (mostly JSON data) ~ 130KB
- HTML ~ 120KB
Compression
The first thing to do is to use compression in IIS and in your CMS.
The first thing to do is to use compression in IIS and in your CMS.
DotNetNuke performance options
Just by enabling DotNetNuke compression, I reduced the page size from 400K to 100K, a huge effect. But if this is not enough, you'll have to fine-tune more.
RadCompression
This is perhaps the easiest thing to do. RadCompression HttpModule will automatically compress your Ajax and JSON web service communication and even your ViewState. Setting up RadCompression is just a matter of adding a HttpModule registration to web.config.
Unfortunately, my experience with RadCompression were short-lived this time. RadCompression (2009.02.0826.35) with IIS6 and DotNetNuke compression broke postbacks in Firefox 3.6! Literally, postbacks returned a garbled mess of compressed text to the browser. Chrome and IE were fine, Firefox too with IIS7. The reason for this was that there was two compressors enabled simultaneously: the DotNetNuke GZip compressor and the Telerik RadCompression. I still have to figure out how to enable RadCompression and disable DNN compression on a per page basis, to speed up Ajax requests.
Measuring the performance impact of RadCompression was not that simple and I didn't get a clear picture. But Chrome Speed Tracer indicated a speedup in refreshing UpdatePanels, that was lost after disabling the HttpModule.
RadScriptManager and RadStyleSheetManager
The purporse of these controls is to reduce HTTP traffic by combining requests, for javascript and css respectively.
RadStyleSheetManager is extremely easy to set up. You just add a RadStyleSheetManager control to your page. The net result was about 10 fewer CSS requests in an empty cache. For a primed cache, there was no effect.
RadScriptManager is trickier. You can have only one ScriptManager per page. Because DotNetNuke has one already, you would have to replace it in DNN core code and rebuild. I can't recommend this to anyone. Hopefully in the future DNN Professional editions this is going to be easier.
Minimize inline javascript
Declare only necessary javacript variables in the ASPX. These are usually the ones where you need ClientIDs, like:
var scheduler = $find('<%= RadScheduler1.ClientID %>');
All other javascript should be loaded from external files and cached.
Try to disable ViewState
Easier said than done. For example, I had a hierachical navigation/drilldown menu that displayed the number of events each year, month and day. I can't disable ViewState for this control, because it is tied to the RadScheduler's view (month, week, day, timeline). Surprisingly, I can disable ViewState in the RadScheduler itself without any immediate loss of functionality. This reduced (pre-compression) page size about 10%, but is a risky bet.
Try to limit data size
By showing less data on one screen you can in many cases improve both performance and user experience. But sometimes you need data for things like RadScheduler appointment tooltips, that are stored in appointment attributes and resources. These take easily a lot of space.
Forget old browsers
Even with aggressive tuning, the overall user experience is very much dependent on the browser's capabilities. With IE6 and other older browsers, any page with heavy RadControls barely works, and I wouldn't spend much effort to tweak them.
Even with aggressive tuning, the overall user experience is very much dependent on the browser's capabilities. With IE6 and other older browsers, any page with heavy RadControls barely works, and I wouldn't spend much effort to tweak them.
Top Performance - General Resources
Posts
