We're building an Angular app, and we're trying to figure out how to get some benchmarks on how long it takes to render various pages. I've read about performance.timing
here, but that seems to only be useful with non-single page applications as when I navigate to new views in our app, the timing numbers do not change.
Ideally, we'd be able to insert some code that gets render time for various views and posts it our our Big Query service.
Any ideas on how to get some timing information for views in an Angular app?
EDIT:
More specifically, you go to a route which loads a big ng-repeat list (which is not optimal for performance), and the window has a long delay before it actually renders the items in the list. We'd like to see how long it takes to go from the big blank view to rendering the items in the list.
TypeScript / Angular (2+) answer:
To benchmark the time spent in Angular rendering the component tree, measure before and after change detection. This will time how long it takes Angular to create all the child components and evaluate ngIf
s / ngFor
s etc.
Sometimes when change detection runs, nothing will have changed and the timed interval will be small. Just look for the longest time interval and that's probably where all the work is happening. Also, best to use OnPush change detection strategy for this. See http://blog.angular-university.io/onpush-change-detection-how-it-works/
Declare this Timer utility above your @Component({...}) class
:
class Timer {
readonly start = performance.now();
constructor(private readonly name: string) {}
stop() {
const time = performance.now() - this.start;
console.log('Timer:', this.name, 'finished in', Math.round(time), 'ms');
}
}
Add this inside your component class:
private t: Timer;
// When change detection begins
ngDoCheck() {
this.t = new Timer('component 1 render');
}
// When change detection has finished:
// child components created, all *ngIfs evaluated
ngAfterViewChecked() {
this.t.stop(); // Prints the time elapsed to the JS console.
}
Note that Angular rendering is separate from the browser rendering (painting) on the screen. That takes time too. When you see javascript (yellow) with lots of "checkAndUpdateView" and "callViewAction" calls in the Chrome Timeline Tool (javascript developer console -> performance -> record) that is Angular rendering happening. When you see purple in the Chrome Timeline Tool, labelled "rendering", that is actual browser rendering.
After doing some experimentation, I found a way to get an approximation how long a view takes to render.
The scenario:
ng-repeat
ul
In an Angular app, ng-repeat
is a notorious performance killer, but it's extremely convenient. Here's a discussion on the performance and here.
Let's say that we want to get an approximation of the time it takes to get from #3 to #4, as testing the AJAX call performance is pretty straightforward.
Here's some context:
<ul>
<li ng-repeat="item in items">
{{item.name}}
<!-- More content here -->
</li>
</ul>
And inside the Angular controller:
// Get items to populate ng-repeater
MyApiService.getItems(query)
.then( function (data) {
$scope.items = data;
// When callback finishes, Angular will process items
// and prepare to load into DOM
}, function (reason) {
console.log(reason);
});
The events mentioned by @runTarm, $routeChangeStart
, $routeChangeSuccess
, and $viewContentLoaded
fire as soon as the route is loaded, but before the DOM renders the items, so they don't solve the issue. However, through experimentation, I found that once the AJAX callback finishes and sets $scope.items
, Angular begins a blocking operation of processing items
and preparing the ng-repeat
ul
to be inserted into the DOM. Thus, if you get the time after your AJAX call finishes, and get the time again in a setTimeout
specified in the callback, the setTimeout
callback will be queued to wait until Angular is done with the repeater process and get you the time a split second before the DOM renders, giving you the closest approximation for rendering time. It won't be actual render time, but the slow part for us is not the DOM doing it's work, but Angular, which is what we're looking to measure.
Here's the revised example:
// Get items to populate ng-repeater
MyApiService.getItems(query)
.then( function (data) {
var start = new Date();
$scope.items = data;
// When callback finishes, Angular will process items
// and prepare to load into DOM
setTimeout( function () {
// Logs when Angular is done processing repeater
console.log('Process time: ' + (new Date() - start));
}); // Leave timeout empty to fire on next tick
}, function (reason) {
console.log(reason);
});
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With