Performance nativescript/angular


hi all,

I’m a new developer on nativescript (just arround a month ago). I choosen to start my app developping with nativescript and angular but i’m experimenting serious problems to performance.

for one side, my app takes at least 15s to start… i readed about the problem and i always find the same solution, Webpack. i’m not capable to make it works, i have another topic with this problem. this is the link:

* Webpack problem.

For another side, the navigation is too slow… When i open a component at first time in another route takes around 3 seconds to start… (the following times it takes less)

I have the following versions:

And my package.json looks like this:

  "description": "xxxx App",
  "license": "",
  "readme": "xxxxx Application",
  "keywords": [
  "author": "xxxxx  <>",
  "nativescript": {
    "id": "",
    "tns-android": {
      "version": "2.5.0"
  "scripts": {
    "tslint": "tslint \"app/**/*.ts\""
  "android": {
    "v8Flags": "--nolazy --expose_gc",
    "codeCache": "true"
  "dependencies": {
    "@angular/common": "~2.3.1",
    "@angular/compiler": "~2.3.1",
    "@angular/core": "~2.3.1",
    "@angular/forms": "~2.3.1",
    "@angular/http": "~2.3.1",
    "@angular/platform-browser": "~2.3.1",
    "@angular/platform-browser-dynamic": "~2.3.1",
    "@angular/router": "~3.3.1",
    "email-validator": "1.0.4",
    "nativescript-angular": "1.3.0",
    "nativescript-camera": "0.0.8",
    "nativescript-cardview": "^1.3.0",
    "nativescript-contacts": "^1.5.0",
    "nativescript-drop-down": "^1.5.1",
    "nativescript-geolocation": "0.0.18",
    "nativescript-google-maps-sdk": "^1.4.3",
    "nativescript-google-places": "0.0.3",
    "nativescript-imagepicker": "^2.4.1",
    "nativescript-iqkeyboardmanager": "1.0.1",
    "nativescript-material-icons": "^1.0.3",
    "nativescript-ng2-slides": "0.0.8",
    "nativescript-ngx-fonticon": "^2.0.0",
    "nativescript-parallax": "^1.1.0",
    "nativescript-permissions": "^1.2.2",
    "nativescript-phone": "^1.2.4",
    "nativescript-plugin-firebase": "^3.9.0",
    "nativescript-push-notifications": "^0.1.0",
    "nativescript-social-share": "1.3.1",
    "nativescript-telerik-ui": "^1.5.1",
    "nativescript-unit-test-runner": "^0.3.3",
    "ng2-page-slider": "^0.9.0",
    "reflect-metadata": "^0.1.8",
    "rxjs": "5.0.0-rc.4",
    "tns-android": "^2.5.0",
    "tns-core-modules": "2.5"
  "devDependencies": {
    "babel-traverse": "6.8.0",
    "babel-types": "6.8.1",
    "babylon": "6.8.0",
    "codelyzer": "0.0.28",
    "filewalker": "0.1.2",
    "jasmine-core": "^2.4.1",
    "karma": "^1.2.0",
    "karma-jasmine": "^1.0.2",
    "karma-nativescript-launcher": "^0.4.0",
    "lazy": "1.0.11",
    "nativescript-dev-sass": "^0.4.1",
    "nativescript-dev-typescript": "^0.3.2",
    "tslint": "^3.14.0",
    "typescript": "~2.0.10",
    "zone.js": "~0.7.2"

I attach my routes structure that is based on groceries example app (for me groceries app takes arround 11 seconds to start too) :

Plunker with the main files

and i use


to open a component

I’m really worried about this. Someone who can help me?


nothing? :slight_smile:


Give vanilla/core NativeScript a try. Boot times are like 1.5s and navigation is less than 50ms.


Yes, vanilla will always be faster, but the whole point of asking for angular performance is that we want to develop with angular, it’s the main selling point for most of us.

For now i can only hear about webpack and snapshots as solutions to the load time.

For now this post talks about LazyLoading (which most likely will be on Webpack’s side):


Good news is that local snapshot builds are coming (3.1) for Mac and soon for Linux developers too. The process includes ahead of time compilation, webpacking, and snapshotting the package, resulting in a little over 30% startup time improvement.

Due to external limitations (V8 build environment requirements) the tools to get the job done will not be immediately available for NS developers using Windows. But that will come eventually.

If snapshots are not available for you however, you are not out of luck, there are a couple good articles circling the interwebz that explain how to make the most out of lazy loading, ahead of time compilation with webpack techniques!


Good resume.

I’ve been building and comparing NativeScript, NS with Angular (i believe they call it ANS) and React Native, so far the Fastest is React Native with 1~1.5 secs to boot when optimized, then pure NativeScript apps with 1.5~2.5 secs, then Angular in NativeScript with 3.5~4.5.

Though i didn’t made an exhaustive effort in optimizing the Angular one with TreeShaking, LazyLoading, AoT (Ahead of Time compilation), Bundling with Webpack 2, i think it’s still slow compared with it’s competitor which already packs with React out of the Box.

Also if it could match up, the issue is also how much effort is required to match that startup time, there’s a few templates out there that try their best but if they are having a hard time even with open source contributions, what would we mere mortals expect?


To me, NS + Angular is not quite there yet… Apps are quite big (around 20mb, iOS or Android), they take a little to much time to load (I’ve got times ranging from 10 seconds to 20 something), some plugins are not fully compatible unless someone adapts them, and the solutions to all of these problems go from tricky to quite obnoxious.

In my experience, navigation between pages is slower too.

You can use snapshots to make load times shorter but - correct me if I’m wrong- that means an extra 10mb on your already pretty big app (I’m not sure about this, really).

You can generate separate ABIs for Android, OK. But that’s more work to do on the store (you have to upload separate versions, with distinct build numbers). But you can’t do that on iOS, so there’s that.

You can get some very useful plugins out there, but some will require some adaptations or considerations to make them work with Angular.

And then there’s Webpack. You have this very useful plugin to “make it work”, and it somewhat does that. If you’re not doing anything out of the norm, it will work with your NS + Angular project. But eventually you’ll use some plugin, or something which was not considered by the team, it will stop working, and it probably never will… is this NS or Webpack’s fault? I don’t exactly know, but it happens and you can’t get a clear answer anywhere about what you should do, or how to fix the different scenarios where something in this combination of things could go wrong.

I know this is kind of a rant, and maybe I’m asking too much from an open source project (which I’d love to contribute to, but I’m clearly not knowledgeable enough to do so), but I insist: NS + Angular is not quite there yet… It’s lacking, there are too many things to have into consideration and they may be all fixable, but they don’t make for a smooth workflow.

I like the technology, I like what they’re doing, I could live and work with some of these problems (not all of them!), but it needs some serious improvements… Or we could use NS in plain JS haha…

I don’t know.


I completely agree with you, sadly NS + Angular is far from being production ready at this moment.

6 months ago we changed our development framework from Ionic to Nativescript for mainly two reasons: Performance and the chance to use Angular to develop a mobile App.

We have developed a NS+Angular 3.0 App with lazy-loading, AoT, webpack… and, at least in Android (we haven’t tried in iOS yet), performance is really poor.

The main problems for us (and I think for most people) are long startup time, slow navigation and big size of the App. I think the Nativescript team is already aware of these problems and I really hope they are working on them.

Having said that, I think Nativescript is a really good product and I’m sure it’ll get a huge growth if these performance issues are solved.


I could live with the big app size, and could tolerate the slow startup, but when it comes to navigation speed, it’s up to the users… and they won’t like it.

But I agree, NS is a good product in need of a few improvements.


Re: navigation being slow. I recognize the first navigation to a lazily loaded route being slow, but only when preloading has not been enabled. If consecutive navigation to the same route is fast, and the first one is slow, make sure that this is in your app.module.ts:

  imports: [
        {preloadingStrategy: PreloadAllModules} // preloads all modules in the background, after app startup


I think PreloadAllModules doesn’t help very much since it doesn’t load the modules in background (javascript single thread problem), causing the UI to freeze. Please, take a look at this issue:

Based on my experience, using Lazy Loading + PreloadAllModules is like not using Lazy Loading at all, but maybe I’m mistaken.

Is this approach working ok for you?



I wouldn’t have mentioned it if I didn’t know it helps; I can switch off and on lazy loading in my (quite large) Angular app and it makes a measurable difference. Just give it a shot.

Note that the linked issue seems to use incorrect preloading syntax (I added a comment there).

Also note that webpacking and building for release(!) make a bigger impact than lazy loading, so make sure you combine those. On iOS adding an Uglify buildstep helps as well, didn’t test that on Android yet.


Thanks for the info, I’ll try it next time.


Experiencing the exact the 3 issues with latest NS+NG. Like you already said, the major issue is regarding navigation (with the rest we could leave) - any finding in this area?

We actually use “raw” Page objects for child pages which are being pre-created in parent ngAfterViewInit in order to speed up the navigation. It does improve it most of the times, but sometimes even with that it’s lagging a couple of seconds. Moreover we experience a slow resume after a while in the background.


Please check this blog post;

It will help you identify which parts are slow so you can optimize them.


Everyone has issues navigating pages? It’s really fast for me all the time?


I’ve been developing a nativescript + angular app for the past few months. When testing this app on ios performance is peachy. However as the app grew navigation on android became laggy freezing the ui. For me though it’s not every page navigation that lags only sometimes and I’m pretty sure it has to do with when garbage collection happens at the same time as page navigation. I believe this github thread confirms this.

Spent a lot of time trying to optimize, manually calling the garbage collector, messing with the gc throttle params, etc but nothing seems to fix it. The lag spikes can occur when toggling back and forth between two router points with very little ui code on either of the pages being routed to. I do have a lot of angular services though some holding application state; most of which are singletons loaded at start up and specified in the providers section of main ngModule. Out of ideas on how to architect things differently or what to do to fix this.

ps. I’m continually impressed by the hurdles the nativescript team has surmounted and the great work they do. This is the largest problem I’ve encountered trying out the framework and I’m optimistic there is a way around it.


@mast3rd3mon the issues are related to Android only. In iOS the performance is pretty good.

Our app has improved a lot when we’ve updated to NS3.1. Building the app with --snapshot param has also improved the boot. With both changes, our app is booting 30%-40% faster than before.

The lazy-loaded modules now are loaded very fast.

The only remaining big problem for us is the described by @jeffswitzer. I think it is a garbage collection problem too, but I’m not sure.

We are on the way.


I dont think they are android problems, i only get performance issues if i call a function that gets lots of data from my server and thats on android and ios. Apart from that, navigation is incredibly fast.


That is correct, the garbage collection routine is currently the only slow chunk in Angular-powered apps. We are constantly discussing and exploring new ways to improve the times and speed up the runtime or eliminate the time it would take to do GC in {N} Angular.

We’ll let you know when we’ve got more worth sharing about our findings and progress.