AngularJS can have performance problems when you start to scale your application. You may notice that your AngularJS application works well at first but as it grows in complexity, so does its load time. The problem amplifies when the application is opened on mobile device as that tends to be more slower because of obvious performance difference between desktop browser and mobile browser.
But there are ways to avoid such scenarios and enhance the performance of an Angular app.
Here are some ways:
Batarang
Batarang is an excellent Chrome extension for developing and debugging AngularJS apps.
It also offers performance analysis and a dependency graph. If coming into an untested codebase, this would be a useful tool to determine which services should get the most attention.
Reduce Watchers
Reduce the number of watchers in your application. A big cause of slowness in AngularJS applications is because of large numbers of watchers. AngularJS uses dirty checking to check the state of the application by evaluating every watcher and applying changes in what is called the digest cycle. The more watchers you add, the longer you make your digest cycle. If a cycle is over 16ms, your UI will likely be very sluggish. 16ms is the max length if you want to maintain 60fps in your application.
So when are watchers set? The main examples are:
[php] bindings
In some directives (ng-show/ng-hide)
Scope variables
Filters (when piped)
ng-repeat
$scope.$watch[/php]
These watchers will be evaluated on every digest cycle, started by any of the following:
[php]ng-change
ng-model changes
$http events
promises being resolved
$timeout or $interval
Manual calls to $scope.apply and $scope.digest
One-time binding[/php]
One-time Binding
Angular processes the DOM as usual and once the value has been resolved it removes the particular property from it’s internal $watchers list.
Using the single binding syntax is easy and most importantly fast. The syntax is clear and concise, and a real benefit to lowering the $watcher overhead. The less work Angular has to do, the more responsive our applications will become.
For example,
[php]<div ng-class=”::{‘no-text-transform’ : ‘post.user.is_admin’’}”></div>[/php]
Avoid ng-repeat Where Possible
Ng-repeat is an incredibly powerful part of AngularJS and often easy to abuse and misuse. Having nested ng-repeats is a quick and easy way to increase your watcher count exponentially and should be avoided if at all possible.
You should also avoid functions in your html that attempt to determine the array to use in the ng-repeat. These functions need to recalculated even when there is no change, unnecessarily reloading the ng-repeat each time. Instead, try limiting the array to a fixed number and then track the ng-repeat by the index (better still, give each item a unique id). Doing this eliminates the need to create nodes in the DOM each time, it just changes values if needed. Pagination is a good way of limiting the amount of content you need to display and therefore need to watch.
Instead we could use quick-ng-repeat. It provides Shallow list watch (ngRepeat uses deep watch), Animations support, Special service to cause list render outside of digest cycle, Smooth scrolling even on heavy compiled lists, About 200% performance boost
[php]// don't do this
<div ng-repeat="post in posts.list">
</div>[/php]
<div class=”white-blocks post-sec-outer” ng-repeat=”post in posts.list”></div>
[php]// use track by!
<div ng-repeat="post in posts.list track by $index">
</div>[/php]
[php]<div class=”white-blocks post-sec-outer” ng-repeat=”post in posts.list track by $index”></div>[/php]
What does track by actually do?
When posts.list is re-rendered, Angular does not have to rebuild an element which has already been rendered. This speeds up the cycle and avoids useless DOM manipulation.
Avoid repeated filters and Limit DOM filters
Filters are really simple to use, we insert a pipe, the filter name and we’re done. However, Angular runs every single filter twice per $digest cycle once something has changed. This is some pretty heavy lifting. The first run is from the $watchers detecting any changes, the second run is to see if there are further changes that need updated values.
If you are applying filters to the arrays, it’s often best to do this in your javascript as opposed to piping it in the HTML
[php]// don’t do this
Example of filter:
$filter('filter')(array, expression, comparator);[/php]
One time binding does not seem to play well with filters. There seems to be work arounds to make it work, but I think it’s cleaner and more intuitive to simply assign the needed value to a variable (or set it as a property on an object, if you are dealing with a lot of variables).
As we have done in one of our project.
For example,
Previous:
[php]<div class="table-wrap">
<table class="table" ng-show="uploader.queue.length>0">
<thead>
<tr>
<th width="50%"></th>
<th ng-show="uploader.isHTML5"></th>
<th ng-show="uploader.isHTML5"></th>
<th></th>
<th></th>
</tr>
</thead>[/php]
Now:
[php]<div class="table-wrap">
<table class="table" ng-show="uploader.queue.length>0">
<thead>
<tr>
<th width="50%"></th>
<th ng-show="uploader.isHTML5"></th>
<th ng-show="uploader.isHTML5"></th>
<th></th>
<th></th>
</tr>
</thead>[/php]
You can do:
– In JavaScript $scope.translateKeyObj.btn_edit : gettextCatalog.getString("btn_edit")
– In HTML
[php]$scope.translateKeyObj = { };
$scope.getText = function() {
$scope.translateKeyObj.wall_lbl_filter_by = gettextCatalog.getString("wall_lbl_filter_by");
$scope.translateKeyObj.btn_delete = gettextCatalog.getString("btn_delete");
$scope.translateKeyObj.btn_edit = gettextCatalog.getString("btn_edit");
$scope.translateKeyObj.btn_report_abuse = gettextCatalog.getString("btn_report_abuse");
$scope.translateKeyObj.lbl_view_more = gettextCatalog.getString("lbl_view_more");
$scope.translateKeyObj.btn_like = gettextCatalog.getString("btn_like");
$scope.translateKeyObj.btn_comment = gettextCatalog.getString("btn_comment");
$scope.translateKeyObj.btn_share = gettextCatalog.getString("btn_share");[/php]
Filters are something to also be avoided as much as possible when using within a loop.
Use ng-if instead of ng-show (but confirm that ng-if is actually better for your use case)
The two directives achieve the same result but in different ways:
* ng-show will render an element, and use display:none to hide it,
* ng-if will actually removes the element from DOM, and will re-create it, if it’s needed.
You may need ng-show for an elements that toggles on an off often, but for 95% of the time, ng-if is a better way to go.
Use $watchCollection instead of $watch (with a 3rd parameter)
$watch with only 2 parameters, is fast. However, Angular supports a 3rd parameter to this function, that can look like this: $watch('value', function(){}, true). The third parameter, tells Angular to perform deep checking, meaning to check every property of the object, which could be very expensive.
To address this performance issue, Angular added $watchCollection('value', function(){}). $watchCollection acts almost like $watch with a 3rd parameter, except it only checks the first layer of object’s properties, thus greatly improving the performance.
I hope you found the above blog informative and we would be glad if it could contribute in optimizing the performance of your Angular JS App.
To read more of such posts around web and mobile technology, subscribe to our blog and we will keep you posted.