RadEditor loads slowly (high CPU utilization)

• Slow loading on development machine
• Slow loading on client with high CPU utilization

• Development machine
• Client machine - RadEditor v4.x
• Client machine - RadEditor v5.x - v7.x

 

BACKGROUND
There are several different reasons for the slow loading time of RadEditor:

Slow loading on development machine
The slow loading of the editor occurs when you are in debug mode in Visual Studio and when you try to start the project from within VS. When RadEditor loads the css styles to the styles dropdown, Visual Studio checks their consistency and thus the slow loading time.

Slow loading on client with high CPU utilization
RadEditor is a very powerful tool with many functions which need to load on the client in order for the editor to operate properly and show its true power. This is the reason for the slow loading time. If you compare it to a regular textarea, you will notice that the textarea loads in no time but offers very limited functionality. The editor, on the other hand, has a large feature set: 

• Unlimited level undo/redo which does not depend on the browser;
• Excellent cross browser support;
• Dockable toolbars and modules;
• Flexible API, useful for accomplishing custom scenarios with very little code

All of this together is implemented in javascript and adds to the loading time. Since the release of v5.0, we are constantly optimizing and improving Radeditor's loading time and we will do it in the future. However, there is a tradeoff between features and loading speed.

Yet another reason for the slow loading time is many instances of RadEditor and RadSpell on a single page. In this case, the page will load considerably slower and occasionally you may get this error:
"You don't have permission to access this page or your cookie has expired!  Please, refresh the page!"
This error is not connected to the slow loading speed. Rather, it is with the sheer number of editors and spells that you set on your page. The HTTP protocol allows only 20 cookies per host. When this number is exceeded the oldest cookie gets dumped.
The editor and the spell each use a cookie to store some information (although the spell cookie does not get written on page load but on initialization).

SOLUTION
Below are described the ways to increase the editor's loading time:

Development machine

1. Disable the "Class" tool from the ToolsFile.xml used by RadEditor.
2. Use a smaller number of CSS classes for faster loading time.
3. Start the project from your browser - everything should be fine there.

Client machine - RadEditor v4.x

1. [most improvement] Remove the CSS class tool from the ToolsFile.xml OR set only the needed CSS classes, rather than leaving the RadEditor to read all of the CSS classes and populate the CSS dropdown with all of them. Setting a small CSS list would skip processing all styles. You can do this from the RadControls/Editor/Tools.xml file or from the codebehind (please consult documentation if necessary).
2. [most improvement] Remove the Paragraph tool from the ToolsFile.xml.
3. In RadControls/Editor/MainIE.js locate the lines that start with
   
   eval("RadEditorAnchorCssClasses"
   eval("radCssClassArray_
   
   and delete them. This is code that parses the stylesheets and produces custom css arrays for the editor dialogs.
4. If you have many editors on the page:
   • limit the cookies to less than 20, preferably around 16 to accommodate for some extra cookies like the session cookie. For example, rather than using the editor's little pencil icon for them to edit a field, give it your own pencil icon and just render it as a DIV tag.  When they click on your pencil icon, with your server-side code, replace that DIV tag with an actual editor. This will significantly increase the load times (network transfer, client-side load, and maybe even server-side load) at the cost of a few postbacks;
   • set the UseSession property to false.
5. Provide ToolsFile.xml with less tools for the toolbar (i.e. remove the tools you will not need).
6. Reduce the number of links in the Custom Links dropdown.
7. Use a very short ID for the editor control (e.g. "Edit" instead of "RadEditor1").
8. The snippets dropdown also slows down the performance when populated with large HTML snippets.
9. Disable the RadEditor ViewState by setting the EnableViewState property to "false".
10. Make sure that the client's browser cache is enabled (this is the default option for IE) from Tools - Internet Options - General - Settings - Reload page: Automatically.

Client machine - RadEditor v5.x - v7.x

1. [most improvement] Remove all modules from the ToolsFile.xml file (the <modules> section).
2. [most improvement] Antivirus tools can significantly impact page load time and thus slow down the editor. For example, McAfee Enterprise 8.0 has a feature called 'ScriptScan' that scans the JS on each page. This is leading to 2x to 4x slower page loads.
3. [most improvement] Set EnableDocking to false. This property turns on or off the global functionality for toolbar and module docking.
4. Provide ToolsFile.xml with less tools for the toolbar (i.e. remove the tools you will not need).
5. Reduce the number of links in the Custom Links dropdown or remove the dropdown altogether.
6. The snippets dropdown also slows down the performance when populated with large HTML snippets.
7. Disable the RadEditor ViewState by setting the EnableViewState property to false.
8. Make sure that the client's browser cache is enabled (this is the default option for IE) from Tools - Internet Options - General - Settings - Reload page: Automatically.
9. Set EnableClientSerialize to false. This should turn off client-side cookie that will save the editor's toolbar/module state and positions.

10. Do not let the editor reads its css classes from the page (as is the default) - use the CssFiles array to specify links only to the css files with the needed classes. Even if all the classes from the page should be visible in the editor - it is still much better to link to the css files with the CssFiles array! You can review the CssFiles example for more info: External Css Files.

Client machine - RadEditor for ASP.NET AJAX

RadEditor for ASP.NET AJAX is based on the MS AJAX framework, which provides a number of very useful features and has great built-in functionality that allows the Prometheus suite to have reduced codebase and a large feature set accross all Prometheus controls.

By using MS AJAX we were also able to reduce the loading time of RadEditor for ASP.NET AJAX on the client by 80%.

At present you can take several steps to optimize the loading time

1. Use RadScriptManager control on the page instead of the ScriptManager to combine scripts
2. [Most important] - test the performance only when <compilation debug="false" in your web.config. When it is true, the MS AJAX debugging code kicks in and causes a severe performance hit on the client-side.
3. set EnableViewState = false to avoid the ViewState overhead
4. In case you are not using the most recent RadControls version, you should upgrade to the latest Q1 2009 SP1. The reason is that as of Q1 2009 the server-side rendering time of RadEditor was reduced by 80% (e.g. it takes 1/4th of the time it took prior to Q1)
5. The following two demos will provide you with some additional suggestions how to configure the editor for improved performance.
   Using ToolbarMode - http://demos.telerik.com/aspnet-ajax/editor/examples/toolbarmode/defaultcs.aspx
   Using ToolProviderID - http://demos.telerik.com/aspnet-ajax/editor/examples/toolprovider/defaultcs.aspx
6. There is one other possible approach which describes how a single editor can be used to edit multiple elements on the page, as described here:
   http://www.telerik.com/support/kb/aspnet-ajax/editor/setting-hidden-radeditor-in-edit-mode-on-click-and-putting-it-in-non-editable-mode-onblur.aspx