Rank 1
We are looking closely at the overall download generated by Radcontrols asp.net Ajax Q1. A test page consisting of the following was created
MasterPage including RadMenu and RadScriptManager
Content Page containing RadTabStrip, MultiPage, ComboBox (5), DatePicker, Grid, WindowManager and 28 RadInput fields.
The page is complex, and is used for account maintenance in a membership system. We did not expect it to be small, or a quick download, but what we are experiencing is much worse than expected.
If we perform as File Save As, Web Page (complete) in IE 7, the result is a 230k html page, and an associated folder which contains over 800k worth of files, the vast majority of which are .axd files
Telerik.Web.Ui.WebResource.axd (462k!)
ScriptResource.axd (255k)
ScriptResouce(1).axd (65k)
Our overall download is over 1 mb! We have tried restructuring the page a number of times to reduce this and improve performance but nothing seems to change the size. Is the above scenario normal for the product as this seems excessive. Please comment.
3 Answers, 1 is accepted
I am very sorry to hear about your frustration with performance while using Telerik RadControls.
We have a lot of optimization techniques for RadControls and I am sure some of them will be of great help for your project. You have not specified which controls (and which version) from the suite you are using so I will just go ahead and summarize the most important performance info we already have in our documentation resources. If the info below does not help, please do not hesitate to provide some further details and send us a sample of your project where you experience the performance issues and we will gladly look into it. While having a GoToMeeting session is definitely an option, our experience shows that improvements are more efficient and much quicker to implement if we review some of your source code before that.
Optimization Tips series in the blogs:
Optimization Tips:The Rad Managers for ASP.NET AJAX
Optimization Tips: Testing Page Performance
Optimization Tips: Using RadAjaxManagerProxy Controls
Optimization Tips: Using HTTP Compression
Optimization Tips: Optimizing Custom Skins
RadGrid
- server-side: The grid itself cannot cause server-side performance problems related to controls creations and/or render. There might be some possible problems with controls inside grid templates.
- data-binding: The .NET 2.0 version of the grid is optimized to handle up to 100 000 records without major performance problems. Server-side paging will increase performance dramatically.
Example: http://www.telerik.com/DEMOS/ASPNET/Prometheus/Grid/Examples/Programming/CustomPaging/DefaultCS.aspx
.NET 3.5 version can handle millions of records and will apply paging, sorting and filtering directly on the data-base server (LinqDataSource) codeless:
Client-side data-binding approach is also very fast + you will get pure JSON transfer between client and server:
- ViewState size: Some of the grid operations can work with completely turned off ViewState.
Example: http://www.telerik.com/DEMOS/ASPNET/Prometheus/Grid/Examples/Programming/ViewState/DefaultCS.aspx
In client-side data-binding scenarios you do not need the ViewState also:
- HTML output size: RadGrid output is the smallest on the market however may depend on selected grid features, number of items per page and templates.
- JavaScript file size: The entire grid script size is 174 Kb (combined and compressed using dojo)
- JavaScript $create clause size: Depends on selected features. Can be turned off along with all other resources:
- Number of requests: Most of the grid images come from the grid CSS sprite which minimizes number of requests to the server for resources. Can be minimized with RadScriptManager and RadStyleSheetManager.
- Other: http://www.telerik.com/help/aspnet-ajax/grdviewstatereductiontechniques.html
RadEditor
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:
1. Having many editors on the page (10, 20 or even 30. More common in MOSS scenarios).
The Prometheus editor 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:
http://www.telerik.com/DEMOS/ASPNET/Prometheus/Editor/Examples/ToolProvider/DefaultCS.aspx
2. 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.
RadTreeView
The biggest challenge here is to deliver acceptable performance when dealing with lots of nodes (hundreds and thousands). To do so RadTreeView supports:
1. HTML markup
RadTreeView 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.
2. Load on demand
The idea is simple - render that HTML only when needed. RadTreeView supports three different types of load on demand:
a. 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.
b. 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.
c. Web-services
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.
3. Initialization of the client object
RadTreeView supports on demand initialization of nodes which are not visible (their parent nodes are collapsed). This is transparent to the user. However, invoking the client-side API (e.g. get_allNodes()) can force full client-side initialization which is a time consuming operation in case of a few hundred nodes. Also logging client side changes which need to be reflected on the server (checking a node, selecting a node) from the client-side API can be slow with lots of nodes.
4. JSON
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.
A QSF example demonstrating web-service load on demand with disabled viewstate will demonstrate the top performance achievable with RadTreeView. Also the performance section of the help provides some further insights.
RadComboBox
Again performance might degrade with lots of items and lots of combobox instances. This is addressed by using load on demand.
1. HTML markup
RadComboBox renders unordered list for its dropdown which is quite light. This is the least amount of html required to render the dropdown.
2. Load on demand
RadComboBox supports two types of load on demand (with caching of items):
a. Web-Service
b. Callbacks (ASP.NET 2.0 Callbacks)
RadMenu
It supports web service load on demand and lazy initialization (transparent for the user). 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.
RadAjaxManager & RadAjaxPanel
Performance problems can be caused by large updating areas with lots of HTML (especially tables), JavaScript files, JavaScript components and CSS. More info: http://www.telerik.com/help/aspnet-ajax/ajxclientsideperformance.html
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
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://www.telerik.com/DEMOS/ASPNET/Prometheus/ToolTip/Examples/RadToolTipManagerClientAPI/DefaultCS.aspx
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.
RadScheduler
Greetings,
Paul
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.
Rank 1
Rank 2
Expanding on what Paul said, also make sure that you've got Compilation debug set to "false" in your web.config. If this is "true," a lot of extra debugging code will be downloaded to your machine that will affect your results.
Also, I'm a little concerned by your use of 28 rich text boxes on a single page. Do you need the rich functionality for all 28 input fields? If you don't, using "plain" textboxes where you can will help reduce unnecessary page girth. Same goes for your RadComboboxes. By trimming (or optimizing) the use of those objects on your page, I think you should get much better results.
-Todd