In this article we will go ahead and summarize the most important performance info we already have in our documentation resources. Optimization Tips series in the blogs:
Optimization Tips: Testing Page Performance
Optimization Tips:The Rad Managers for ASP.NET AJAX
Optimization Tips: Using RadAjaxManagerProxy Controls
Optimization Tips: Using HTTP Compression
Optimization Tips: Optimizing Custom Skins
Some optimization features introduced in the ASP.NET AJAX version are:
semantic rendering to reduce HTML markup
certain editor scripts are loaded only if needed, reducing total script sent to client
use of optimized code relying on the common Prometheus framework
lazy initialization and loading for any client-side feature not immediately used.
Nonetheless, there are two scenarios where performance can degrade:
Having many editors on the page (10, 20 or even 30. More common in MOSS scenarios).
RadEditor for ASP.NET AJAX initializes about 3-4 times faster than the Classic version on the client side.
Nonetheless, having 30 instances of the editor is bound to cause a delay. However, this delay can be greatly reduced and brought to almost nothing
– by setting a ToolProviderID (so that many editors share the same toolbar and no additional markup is sent on client), as well as set the ToolbarMode property – non default toolbars use lazy initialization and are initialized not when the page loads, but when an editor is first used (e.g. the user clicks in the content area). The following example demonstrates these two features:
Loading too much content into the editor (100K and more).This is done very rarely, but sometimes we get contacted about slow performance of the editor. Problem is not addressable – it is inherent. When having to deal with so much content, the browser eats lots of memory to provide for storing the editor states needed by the Undo/Redo, the Undo/Redo itself starts executing slowly due to the huge content.
The biggest challenge here is to deliver acceptable performance when dealing with lots of nodes (hundreds and thousands). To do so RadTreeView supports:
HTML markupRadTreeView renders the least amount of HTML needed to implement the features. However, the HTML size grows up dramatically when RadTreeView contains a few thousand of nodes. This issue cannot be easily tackled - even rendering a few thousand strings will generate lots of output. That’s where load on demand comes into play.
Load on demandThe idea is simple - render that HTML only when needed. RadTreeView supports three different types of load on demand:
Client-side (via ASP.NET Callbacks)
This is technique is easier for the developer to implement however may not be a top performer because the whole ViewState is submitted on every request.
Server-side (regular postbacks which can be ajaxified)
Worst performance. Mostly added for backwards compatibility. Full page update can be avoided by wrapping the treeview inside update panel.
Web services provide best performance because they completely skip the heavy page lifecycle and don’t require sending huge ViewState strings.
All types of load on demand keep logging the nodes created on demand. This however introduces a delay after numerous loads on demand requests since the log grows bigger. This is required by customers who want the nodes created on demand do be persisted after postback (or those nodes need to fire server-side events - click, drag and drop etc). This means that after some time all load on demand schemes (without server-side) get slower. Fortunately, there is a property PersistLoadOnDemandNodes which controls this behavior.
performance section of the help provides some further insights.
Again performance might degrade with lots of items and lots of combobox instances. This is addressed by using load on demand.
HTML markupRadComboBox renders unordered list for its dropdown which is quite light. This is the least amount of html required to render the dropdown.
Load on demandRadComboBox supports two types of load on demand (with caching of items):
Callbacks (ASP.NET 2.0 Callbacks)
It supports web service load on demand and lazy initialization (transparent for the user). RadMenu can seamlessly work with disabled ViewState.
Having lots of page views (inside RadMultiPage) can slow down switching between tabs. Also it generates lots of HTML (because of the controls contained in the pageviews). To tackle this problem we have an
Optimizing client-side performance
RadDatePicker, RadDateTimePicker and RadTimePicker
Performance problems can be caused by using the picker in list controls. An example how to optimize this can be found here:
RadDateInput, RadNumericInput, RadMaskedTextBox and RadTextBox
Performance problems can be caused by using these controls in templates of list controls. A better idea is to create an outside edit form similar to this example:
RadTooltip RadTooltipManager are quite lightweight and generally there are no problems with performance. However, in templated scenarios the number of tooltip controls on the page can easily go out of hand. We have seen scenarios involving 1000+ tooltips on a single page. Since each of them needs to be initialized on client page load, the system takes a lot of time to do it, especially If <compilation debug=true>. In such scenarios there is a better approach to the tooltips – and that is using a couple of lines of client-side code that will create a tooltip only when the user needs to see it. The following demo demonstrates this approach:http://demos.telerik.com/aspnet-ajax/ToolTip/Examples/RadToolTipManagerClientAPI/DefaultCS.aspx
A brand new mechanism for updating RadSplitter's child controls was introduced that is many times faster than the old one which traversed every single HTML element to test whether it is a RadControl.
Data-binding: We recommend that customers bind RadScheduler only with appointments that are visible in the currently selected view. This makes performance a non-issue, as the views are limited to a few thousand appointments at maximum.
ViewState size: RadScheduler can work entirely without ViewState, if necessary. Customers pay the usual penalty of having to bind the data on each page load.
Number of requests: On-demand loading of scripts generates a few additional requests. Other than that, the number is rather low, as skins contain very little number of images. Using RadScriptManager and RadStyleSheetManager reduces the number even further.
RadScriptManager and RadStyleSheetManager
When loading a page with several controls on it, the number of these files can become very large, often resulting in a reduced page load time and increased traffic. The reason for this problem is that browsers make separate requests to the server for each of these resources.
Usually this problem is overcome by disabling the automatic script and stylesheet serving the controls, combining them into a smaller set of files and manually registering the links to these files in the page.
This approach is not the best for a number of reasons:- you must extract the files from the assembly for each control release;- files become too large to be maintainable (or you have to write a script to merge the source files);- the number of the merged files you need to maintain can become very large depending on the control sets you have on different pages;
With the newly added
controls, RadControls for ASP.NET AJAX suite gives developers the advantage of a simple drag-and-drop to achieve the combination of resources to a single request. All you need is to add a
RadStyleSheetManager to the page makes the stylesheet requests combined into a single request.Both controls need an HttpHandler to be declared in the application's configuration file to operate properly. The handler can easily added using the Smart Tags of the controls.