Editor’s Note: This post is the final in a three part series where we’ve talked about improving the SugarCRM client side user experience. Previous parts of the series focused on server side and client side performance and what can be done to improve things. In this part, Senior Engineer David Wheeler highlights the new AJAX UI coming to all editions of Sugar 6.3, which provides increased client-side performance and lower server load by using AJAX techniques to optimize the page load.
In version 6.3 of SugarCRM we are introducing a new method for loading pages that uses AJAX to load the html content rather than doing a full page refresh. This has some major impacts on performance. The biggest gains are:
- No full rebuild of the Dom: Rather than destroying and rebuilding the entire Dom tree, only the center content area is updated.
- Fewer requests per page: When a web server is configured to set very large cache timeouts, this isn’t a very big deal. The client will only load the script, image, and style files once and never make a request for them again until Sugar is updated. However, many servers are not configured this way and the client will make a request to the server, even if it is just to verify the cache isn’t out of date, for every single resource on a page. This can mean up to 100 requests for some pages. With the AjaxUI, these files stay in memory until the user closes the browser even if the cache expire is not configured. For a connection with a high ping, it can make a page load time go from tens of seconds for 50 requests down to a single request taking under a second.
There are some side effects of the AjaxUI that can cause issues with customizations.
you couldn’t guarantee that the second bock would fire only once jquery had loaded. To help with this problem, we’ve added a function to Sugar called SUGAR.util.doWhen. It has an signature similar to onContentReady except that instead of only wait for Dom elements to appear, it can wait for any condition to be true. The first parameter can either be a string to be evaluated or a function to call, but as soon as either is true, the function passed as the second parameter is fired. So using doWhen, the above block could either look like:
- JSON responses: The final thing to watch out for is php warnings and errors causing invalid server responses. These kinds of errors being displayed won’t cause the same level of headache with a normal UI as the user can often just ignore them and continue until the admin gets around to fixing them. With the AjaxUI, the errors can cause the server response to become invalid and the page fail to load entirely. On a production instance these errors and warnings should be logged rather than shown to the user anyhow, but with 6.3 you might want to double check your settings. Also, if you have a customization that tries to bypass the MVC Controller and send content directly, it could also run afoul of this issue.
If any of these problems crop up and can’t be fixed easily, you also have option of disabling the AjaxUI for a single module or across the entire app. Starting with 6.3 RC1, there will be an admin section for disabling the AjaxUI on a per module basis. It can also be done manually in the config override with a line like:
$sugar_config['addAjaxBannedModules'] = "Contacts";
That would cause links to the Contacts module in the app no longer attempt to load via the AjaxUI, and use the normal URL structure.
You also have the option of totally disabling the AjaxUI with the following line.