Angular view performance related to placing ng-app / ng-controller in DOM
I was wondering if I could get a significant performance difference in my Angular app (specifically handling the view) if I changed the placement of attributes ng-app
and ng-controller
from ie body
to some block element on a page of a much smaller DOM subtree?
Let's say I have a very long page with a huge amount of content, but only part of it is Angular in action. Everything else is either server generated, which means it is somewhat static from the client software.
Wouldn't it be better to ng-app/ng-controller
only place them in the node where Angular actually runs, or would it be the same if I placed them in an element of body
this very long page?
Does Angular only view the sub-DOM where ng-app/ng-controller
defined or does it still process the entire DOM?
Is there any evidence for this or even Angular documentation?
source to share
Theoretically / potentially? Yes, as New Dev mentions, the function bootstrap
will have a larger DOM to run compile
on, which will take longer than compiling a smaller tree.
Practically? Probably not. But your best bet is to check your own page.
As an experiment, you can try the following. I created a simple random DOM and injected it into the JSFiddle from console.time
starting with the script loading and ending when the controller is ready. There's a little auxiliary tree nearby (like a sibling) much larger, 5000-node.
Here's the fiddle wrapping the whole body: http://jsfiddle.net/gruagq8d/
And here's a fiddle where only a small subset is used: http://jsfiddle.net/h0hod2j8/
For me, running any of these scripts converges multiple times at about 260ms.
I've also tried similar code on real webpage sources like StackOverflow itself and found the same results (however I haven't posted any of them because other people's posting on real JSFiddle pages is not compliant without permission) - you you can try this for yourself pretty trivial.
Admittedly, this doesn't fit a lot of benchmarking methodology, but if wrapping a lot of extra DOM nodes caused significantly different performance, I would still expect at least some difference in them.
I don't think the extra compilation time is an issue; for small DOMs this is obviously fast, and for large DOMs it is very important compared to the time it takes your browser to create the DOM in the first place.
All that said, as mentioned earlier, your best bet is to try and run similar tests with your own page.
EDIT: Modifying the same benchmark to test the digest loops shows that there is no significant difference between them:
Minimum packaging: http://jsfiddle.net/fsyfn1ee/
Wrapping the entire DOM: http://jsfiddle.net/04tdwxhp/
source to share
ng-app
really just points to the root element that Angular is calling on angular.bootstrap
. bootstrap
starts the "compilation" process, that is, it iterates over each DOM element in the root subtree and collects directives from it and links them.
Right there, you can see the benefit of limiting your application to a smaller DOM subtree:
- The compilation process is slightly faster
- Smaller directives are compiled (e.g.
<input>
items that should not be part of the application are not compiled / linked).
Keep in mind that it is the $ digest loop that is a significant source of performance / optimization issues - that is, number $watchers
and speed "$watchers"
.
source to share
The official docs say that only the part enclosed in the directive is compiled ng-app
.
If the ng-app directive is found then Angular will:
- load the module associated with the directive.
- create application
- the injector compiles the DOM by treating the ng-app directive as the compilation root. This allows you to tell this only for the DOM part as an Angular app.
This is pretty much expected since Angular allows you to have multiple Angular modules managing independent parts of the same page (manual loading required as pointed out by Josiah Keller in the comments). And their areas won't get in the way.
However, adding additional static html (not Angular bound) only affects performance on load. Yes Angular has to compile all these elements in bootstrap to see if it will deal with them later.
But runtime performance mostly depends on $watch
s. An implicit form of their creation is to make bindings. Thus, the more bindings you have overall, the longer the cycle will take $digest
. And it gives an overall feeling of a slow application. I met a reasonable 2k clock threshold for a modern browser / CPU
source to share