Top Performance
At Telerik, we know that claims about being “the fastest” or “the richest” or “the most complete” mean nothing withoutfacts to back them up. So for everyone out there that says, “prove it!” this is the page for you.We have assembled a host of facts and data about the RadControls for ASP.NET AJAX to show you how theyare in fact the fastest, richest, and most complete .NET UI components on the market.
Before you dig-in to the facts, though, it’s important to understand that “top performance” means a lot more than “fast loading.” While fast load times are important, and Telerik certainly excels in that category, you must consider how a UI component impacts all aspects of your application- from SEO to accessibility to developer productivity- before you can claim “top performance.” Our product teams recognize this challenge and attack all angles of delivering true top performance with every release.
The facts below explain how we’re attacking these performance issues for many of our key controls.This is an expanding resource, too. We will continue to add more information to this page in the future,making it your “go to page” for proof that the RadControls are the best.
General Resources
Every tool that Telerik makes is designed with high performance optimization in mind.You can find many articles in the Telerik documentation (telerik.com/help) that focus specifically onhelping you optimize your RadControl implementations. For more optimization tips, check out these articles from theTelerik Optimization Tips blog series:
Optimization Tips series in the blogs:
Jump to...
RadGrid
When picking a grid control, it’s important to focus on features, ease of configuration, page load time,performance with large data sets, and support for advanced optimization techniques. Let’s see howRadGrid addresses each of these requirements.
Features
RadGrid has hundreds of features built-in, everything from pop-up data editing andfiltering to client-side column reordering and 12 built-in skins. Setting simpleproperties can control almost all features, and rich visual configurators and SmartTags in Visual Studiomake the setup task even easier. Our online demos highlight many of the Grid’s features, complete with source code, so you cansee “behind the curtain” and realize there is no magic happening here.
See RadGrid features in action
Page Load Performance
Good features aren’t good enough to make a grid great. They need to load lightning fast and not interrupt the user experience. RadGrid’s total JavaScript payload- for all features- is only 174KB. The RadGrid also leverages CSS and sprites to minimize the Grid’s HTML footprint and to reduce the number of requests the Grid requires to load. In fact, the RadGrid renders the smallest HTML footprint and generates the smallest number of request of any commercial data grid.
See RadGrid lightweight HTML in action
Handling Large Data Sets
Grids need to be able to handle large amounts of data on the web. Telerik’s RadGrid is optimized for these scenarios. When using the RadGrid and .NET 2.0, the RadGrid is optimized to load, page, sort, and filter up to 100,000 records. If you use .NET 3.5, RadGrid automatically begins using LINQ-based techniques to easily handle 1 million records without performance problems.
See RadGrid large data processing in action
Advanced Optimization Techniques
There is always a trade-off with UI components between easy of setup and optimized performance. The key is to find a component that makes it easy to add advanced performance optimizations when you need them. The RadGrid exposes a number of techniques for taking full control over performance, such as powerful client-side data binding and complete support for ViewState-less operation. With client-side binding, for example, the RadGrid can page, sort, and filter data with near client-like responsiveness.
See RadGrid client-side data binding in action
See RadGrid ViewState optimization techniques
Accessibility
People often forget the importance of accessibility in web development. If you’re building applications for large enterprises or governments, though, you can’t afford not to address it. RadGrid is fully compliant with Section 508 accessibility guidelines, which means RadGrid can even be accessed by clients that don’t have JavaScript enabled! While many grids claims to be accessible, few truly take the support as far as RadGrid.
See RadGrid running in no JavaScript mode
By the Numbers
The following numbers are based on a simple page with a RadGrid using default settings bound to a LinqDataSource with a query that returns 1,000,000 records, each with 5 columns.
RadGrid for ASP.NET AJAX
| Avg. load time | JavaScript size |
| 74KB | 63 ms |
RadEditor
When picking a rich text editor for the web, the most important criteria are page load time and richness. It also helps to find an editor that has proven itself in the “real world,” and since Telerik’s RadEditor is the preferred choice of Microsoft’s MSDN, Codeplex, and Sharepoint teams, we think you’ll agree you’re in good company.
Page Load Time
The RadEditor for ASP.NET AJAX is one of the richest and fastest loading rich text editors on the web, a combination you don’t often find. When our engineers set out to build the best rich text editor for the web, they recognized that one of the chief requirements was to build an editor that could support sub-second page load time. With RadEditor for ASP.NET AJAX, you get just that.
By loading only the JavaScript for toolbar features that are being used and by using CSS sprites for skinning, the RadEditor loads on average in ¾ of a second on all major browsers- IE, Firefox, Safari, Opera, and so on. Furthermore, tools that are not immediately used by the Editor automatically employ a “lazy loading” technique to ensure even the most complex of Editor configurations do not hurt your page load time.
Need a lot of Editors on your page at one time (SharePoint developers, I’m looking at you)? That’s usually a performance killer for rich text editors, but RadEditor even provides optimization techniques for sharing toolbars between Editor instances, making it possible to have upwards of 20 Editors on a page at one time.
See RadEditor Performance Test results
See RadEditor optimization techniques for many Editors on one page
Richness
There is no question that Microsoft Word is the de facto standard for word processing on the desktop. With RadEditor, you get a comparable level of richness in a web-based environment and support for complex text editing in a standards-based, XHTML-compliant UI component. RadEditor even supports many of the keyboard shortcuts Word users are accustomed to, making it easy for your end-users to use RadEditor (read: less training and customer support).
It would be impossible to capture all of the Editor features in a simple paragraph, but highlights include a built-in inline spellchecker, a rich client-side and server-side extensibility API, a built-in image uploader and editor, and (like all Telerik controls) 11 built-in (and highly optimized) CSS skins. Spend some time with the online demos to see all of these features and more first hand.
See RadEditor features in action
See RadEditor accessibility features
RadEditor by the Numbers
The following numbers are based on a simple page with a RadEditor using default settings loaded in Internet Explorer 7.
RadEditor for ASP.NET AJAX
| Avg. Page load time | 611 ms |
| Number of requests | 19 Requests (w/o RadManagers)
9 JS files, 5 CSS files (3 for RadEditor, 2 for RadWindow), 5 images files (together for RadEditor and RadWindow) |
| JavaScript size | Variable
RadEditor, RadWindow, RadSpell files only – 85 Kb |
RadScheduler
When picking a scheduler control, you must find a control that loads quickly, has a rich, interactive UI, and allows flexible binding to any scheduling data you have.
Page Load Time
Similar to the RadEditor, RadScheduler for ASP.NET AJAX only loads the script files for the features that absolutely necessary on initial page load. Lazy loading is used to load additional scripts as they’re needed, so the end result is a very rich scheduling component that does not negatively impact your page’s initial loading time. Also benefiting RadScheduler’s load time is highly optimized HTML output, ensuring only the bare minimum HTML is rendered so your pages stay lightweight and fast.
See RadScheduler page loading in action
Flexible Data Binding
One of the biggest problems with most web-based scheduling components is that they require you to bind to objects or data sources that implement pre-defined patterns or interfaces. This is okay for new projects, but an absolute showstopper for existing development. Fortunately, with RadScheduler for ASP.NET AJAX you don’t have to worry about where your data is stored. You can bind the Scheduler to any data source or object that contains your scheduling data and still take advantage of all of the rich UI features like drag-and-drop appointments and recurrence.
Further benefiting performance, the Scheduler supports loading only the appointments that are “in view” from your data source. That means you only load data as it’s needed by the Scheduler UI, significantly reducing potentially performance-crushing queries to your data source for data.
See RadScheduler data binding in action
See RadScheduler data optimizations in action
RadScheduler by the Numbers
The following numbers were collected by loading a default RadScheduler on a simple page, bound to 10 appointment items displayed in Week View. The tests were conducted in IE 7.
RadScheduler for ASP.NET AJAX
| Avg. Page load time | 185 ms |
| Number of requests | 22 (w/o RadManagers) |
| JavaScript size | 76 KB
(Varies between view types) |
RadTreeView
When picking a treeview control, the most important factors to consider rich, client-side features and performance with large node collections.
Rich, client-side features
Most users that encounter a treeview control on the web are used to dealing with them on the desktop. They’re a key UI concept in all major operating systems, and as such users- and developers- have a certain level of expectation about what a tree should be able to do. RadTreeview rises to the challenge by supporting all of the rich interactions users expect from a tree in a standards-based, XHTML-compliant UI component. Things like node drag-and-drop (in the same tree, between trees, even between trees and grids), node editing, and node context menus are supported right out of the box. All of this, of course, while rendering highly optimized HTML and loading lightning fast on the page.
See RadTreeView client-side features in action
Page Load Time
The most common problem trees encounter on the web is large node collections that kill page performance. The Telerik engineers recognized this problem early on and provided a number of “load-on-demand” modes to loading nodes as their needed. For top performance, developers can leverage the RadTreeView’s built-in support for web services that enable easy codeless binding to fast and efficient services. With this approach, developers can load nodes as needed without transmitting ViewState and without executing the full ASP.NET page lifecycle, meaning nodes load with little noticeable delay.
See RadTreeView web service optimization
RadTreeView (as well as most of our ASP.NET AJAX controls) renders some JavaScript code in JSON format required to initialize the nodes. At the time being the text of the node is not serialized in by default which saves lots of output.
RadTreeView by the Numbers
To collect these numbers, a simple page with a RadTreeView using default settings is bound to 1,000 nodes (10 x 10 x 10), with all sub-nodes loaded on demand via web services. Tests were conducted in IE 7.
RadTreeView for ASP.NET AJAX
| Avg. Page load time | 30 ms |
| Number of requests | 16 (w/o RadManagers) |
| JavaScript size | 57 KB |
| Time to load sub-nodes | 50 ms per node |
RadComboBox
Combobox controls are used to deliver more functionality than the standard HTML select or ASP.NET DropDownList can provide, so it’s most important to find a control that supports flexible rendering while not significantly impacting page load performance.
Flexible rendering
More often than not, you’ll use a rich combobox control like RadCombobox when you need to render a drop down that supports more than simple string values. That means you need a tool that can render any HTML you want in the drop down list- and that’s exactly what RadCombobox allows you to do. From multi-column support to template support, anything you need in a drop down can be rendered in RadCombobox.
All this flexibility comes packaged in a control that renders lightweight, semantic HTML for optimum page performance and SEO. A RadCombobox renders as an unordered list in the HTML, which means no nested tables are used to build the controls UI (a common “mistake” made by other combobox controls).
See RadCombobox flexible rendering in action
Page Load Time
Similar to the tree controls, the biggest problem comboboxes face is handling large collections of values. Browsers simply have limits on the number of HTML items they can process on a page before memory problems begin to cause serious page performance degradation. To help combat those issues, RadCombobox supports several built-in “load-on-demand” binding modes that enable you to only load list items as they’re needed. And just like RadTreeView, RadCombobox support direct binding to web services for super optimized, JSON updates. It’s still possible to hit browser memory limits with these optimizations, but RadCombobox makes it much easier to avoid those problems with smart loading of your data.
See RadCombobox optimized web service binding
RadCombobox by the Numbers
The numbers below were collected by testing a simple page with a RadCombobox for ASP.NET AJAX bound to a web service that returns 500 values when the combobox is expanded. Tests were conducted in IE 7.
RadCombobox for ASP.NET AJAX
| Avg. Page load time | 25 ms |
| Number of requests | 10 (w/o RadManagers) |
| JavaScript size | 41 KB |
| Time to load list values | 120 ms |
Included with Telerik’s standard UI controls are two controls focused on optimizing the performance of pages that use multiple Telerik controls: RadScriptManager and RadStyleSheetManager. The use of these controls can significantly improve your page load time and quickly optimize your Telerik-based applications.
RadScriptManager
All superset of the standard ASP.NET AJAX ScriptManager, this control automatically combines all JavaScript files for all RadControls on the page. Recall that the number of requests a page generates on initial load is one of the most common performance bottlenecks, so reducing those requests is a good way to improve overall page load time. Simply adding a RadScriptManager to a page with RadControls reduces all requests for JavaScript support files to a single request.
RadStyleSheetManager
This control does for external CSS files what RadScriptManager does for JavaScript. When added to a page, this control will automatically combine all CSS for all RadControls on the page to a single request. Used in conjunction with the RadScriptManager, and a page with many RadControls will only generate one request for CSS, one request for JavaScript, and then a handful of requests for any required image files (since images obviously cannot be combined).
For a complete analysis of how the RadManagers impact page peformance, see this article:
Optimization Tips: The RadManagers for ASP.NET AJAX
RadMenu supports web service load on demand and lazy initialization (transparent for the user). Also, RadMenu can seamlessly work with disabled ViewState.
RadTabStrip
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 online example demonstrating how to load pageviews on demand via AJAX. The multipage also has a property “RenderSelectedPageOnly” which does exactly what it says. In this case switching to a new page view requires postback.
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:
RadSplitter
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.
RadAjaxManager
Performance problems can be caused by large updating areas with lots of HTML (especially tables), JavaScript files, JavaScript components and CSS. More info
RadCalendar
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.
When using text boxes you always need extra functionalities such as parsing and data validation. Usually adding them means increasing page footprint or doing extra coding, this is not the case with RadInputManager. It offers an easy and intuitive way to extend a standard asp.net text box, and without any extra custom code, introduce much functionality, normally related to a Telerik RadInput control.
Page Loading Time
Usually, having a large number of input controls on the page, each associated with a separate object and client events and handlers, would imply a performance hit. Introducing the RadInputManager, however, dramatically reduces the load time. The chart which follows demonstrates the loading time of a standard page, with a total of 300 input controls on one hand, compared to the extension of 300 text box controls.
Maximum Number of Controls
Another aspect of performance is the maximum number of controls allowed on the page. Local tests showed that a standard application would allow no more than 600 input controls on the page. With the help of RadInputManager, however, this number can be increased ten times, to a total of 6000 extended controls.
Page Footprint
Yet another aspect of performance is the footprint of the page. Local tests showed that a standard page, with a total of 300 input controls, generates a footprint of approximately 400KB. On the other hand, extending 300 standard text boxes via the RadInputManager, to enhance their behavior to a NumericInput control, generates a footprint of approximately 100KB. This brings about faster loading and better responsiveness of the page.
Client-side Objects
A normal input control generates a client side object for each control instance. For example, if you declare 300 input controls on the page, you will have 300 client objects, once the page is compiled and ran. On the other hand, when extending standard text boxes, via the RadInputManager control, you will have a single client side object, which would dramatically improve performance, while at the same time providing enhanced data entry capabilities for user input validation.