When you present large number of records at once you will see delays in the grid operations execution. Actually, the problem lies in the browser which cannot handle large amounts of HTML. You can try this with a very large TreeView, Menu, PanelBar, etc. (with thousands of items), or you can even try to select the contents of your page in the browser and you will see 100% CPU utilization for a certain period of time.
Turning off all row-related features (row select, row click, etc.). With every client-side feature of RadGrid a script is transferred to the client.This script will be used to perform the required functionality. More scripts on the client-machine mean worse performance.
Non-optimized images in CSS.
1px background images with background-repeat: repeat-x.
Note: IE has a limit of 31 loaded stylesheets. This limit could be easily overcomed by referencing one stylesheet inside another.
You could use RadInputManager to increase the client-side performance.Using this technique you will significantly decrease the input editors loading time since plain MS TextBoxes will be created(instead of the corresponding RadInput controls) and the data entered by the end user will be automatically filtered by RadInputManager,based on the input manager settings. The performance benefit can be quite significant:
The same number of input controls will be loaded up to 10 times faster
The maximum number of input controls allowed on the page can be 10 times greater. You could check this online demo application for a sample code and performance overview.
Use built-in/custom paging or virtual scrolling/paging and present only fixed set of records at a time - here are online examples for it: Basic paging, Virtual scrolling and paging. In case you have more than 100 records in a flat grid, it is recommended to turn on the build-in paging/custom paging of the grid.This will not only optimize the grid loading time but also will enrich the user experience, thus giving him/her the flexibility to easily navigate through the grid records.When you have a hierarchical grid, the best approach is to limit the items presented in each level at once to 10-15 at most (through the PageSize property of the GridTableView object).
You could disable the ViewState of the control, this will reflect in less data transferred back and forth between the client and server. However, this optimization comes at cost of sacrificing some functionality. You could check the lists of the functions that are not supported when the ViewState is disabled in this help topic. Demo application that describes this functinoality could be found here
When in need to allow the user to have Date input, you may consider using regular TextBox controls and the client-side API of RadDatePicker control. This approach optimizes the performance because the time needed for TextBox initialization is less than the time needed for RadDateInput initialization. This is the demo application that illustrates this approach.
You could use RadAjaxManager controls to Ajax-ify the Grid instance and thus to receive partial updates from the service only for the Grid instance, not the whole page.
Finally could use RadCompression to compress the responce from the server in case of Ajax and service responses.
If you have hierarchical grid, use on demand loading (HierarchyLoadMode.ServerOnDemand) of detail tables with DetailTableDataBind child tables content generation. You can combine these settings with:
- single expand for grid items at the same level
If your grid or several instances of the control reside in page view(s) of RadMultipage (connected to RadTabStrip), we recommend choosing RenderSelectedPageOnly = true for RadMultipage, set AutoPostBack = true for the tabstrip and ajaxify the tabstrip and the multipage via RadAjaxManager. Thus only the active page view will be loaded at a time and merly the grid object residing in that page view will be bound to data, thus reducing the loading and rendering time of the page.
You could use LinqDataSource for which the Grid control will perform aggregate calculations or executes sorting/filtering/paging operations by means of native LINQ expressions. This technique significantly reduce the time necessary to process these actions "behind the scenes" and allows you to handle millions of records within a few seconds. Example that illustrate this behavior could be found here.
You could have client-side binding with caching enabled. Doing this will cause all the data to be stored on the client computer and thus to increasethe performance and the scalability of the server. When caching is enabled the internal operation performed by RadGrid will be done solely on the client without hitting the datasource. Sample application could be seen here.
Instead of providing the whole datasource to RadGrid and wait for it to page the data for you, you could do this manually by using the custom paging functionality that the control provides. In this case data will be loaded only for the current page. This is a demo application that implements custom paging for RadGrid.
If you have Grouping functionality enabled you could set the groups to be load on the client computer. This is the demo application that illustrate this feature.