Summary

For the last project I worked on we decided to go with Angular for a front-end framework because of it's many utilities, low barrier to entry and 2-way data-binding with HTML. Before starting work on the front-end, there was a concern about Angular's ability to react quickly and put content in front of the user, especially on mobile. In order to address these concerns, I set out to find just what Angular can handle and if we could actually break the 1 second time to glass barrier with Angular on mobile. As an additional component, we were using Optimizely to run A/B tests and wanted to see if we could have everything run quickly and still get those tests to run without a FOUC. You can read a bit more about getting those two to play nicely in my Angular + Optimizely post.

Implementation

I started out with a basic angular-fullstack app and decided the best way to test Angular's capabilities with regard to our needs was to throw a whole bunch of DOM changes at it. Creating, updating and removing DOM nodes and making changes to them are pretty slow operations. Especially if those changes involve having to repaint. Simulating something that I hoped would be far in excess of what we needed, I had Angular create hundreds of nodes each with their own 2-way bindings inside of them together representing many thousands of listeners. Each of those nodes and some of the nodes inside of them then had their values changed and finally all of the nodes were deleted. I played around a lot with how to help and hurt performance on this test and added a few more tests with varying conditions from significantly more load to something that I thought was more like what we would create.

Results

Between my own research and the research that I could find that other people have published I could not find any reason to believe Angular has any significant mobile performance issues. In more believable scenarios, I consistently saw sites loading in Angular in under 1 second and in lightweight implementations the sites load in under 600ms on desktops. Mobile load time was consistently about double that of desktop load time. I had read in a couple places that 2000 listeners is about where Angular buckles but I had it running somewhat(under 5 second load time) quickly with many many more listeners than that. I find that pretty acceptable for pushing a framework past it's practical limits. I should note that despite this hopeful outlook, Angular is still MUCH slower than other frameworks. All that power comes at a price. If you need something that puts information on the screen as fast as possible, you might want to consider something lighter.

You can find what's left of my testing playground on GitHub or check out the live demo on Heroku(It's just a free dyno so it might take several seconds to load initially).

Moving forward

The Angular team is working on a version 2.0 which promises to be better organized, much faster and more flexible. I'm really looking forward to seeing what they come up with. There's also the upcoming Object.observe() method that is going to revolutionize MVC frameworks and make data binding much faster. Once this makes it into more browsers, a lot of performance issues(which are mostly caused by tons of dirty checking) will disappear. For another fun read on Angular performance, check out this writeup on how Scalyr eliminated a number of performance hangups.