I have a similar problem with customers complaining about the performance of RadScheduler.
To be fair, in this case, there are other controls besides a RadScheduler on the same page (RadMenu, RadToolbar, RadTreeView). Anyway, the page is heavy on data, and feels sluggish. I did some benchmarking with YSlow and Chrome Speed Tracer, which might be helpful in your situation too.
I found with YSlow that my page was about 1MB in total size.
The problematic part is the generated HTML that has to be loaded each time. This is what you see with the "view source". In my case, the HTML took about 400KB. It contained:
ViewState ~ 150KB
Script (mostly JSON data) ~ 130KB
HTML ~ 120KB
The first thing to do is to use compression. This reduced the page size in my case from 400K to 100K, a huge effect. But if this is not enough, you'll have to tune more.
Declare only necessary javacript variables in the ASPX. These are usually the ones where you need ClientIDs, like:
|var scheduler = $find('<%= RadScheduler1.ClientID %>'); |
Try to disable ViewState
Easier said than done. For example, I had a hierachical navigation / drill down 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 could 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.
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.