Building angular 4 for production, my main.bundle is over 14 mb

[Chikodi Nwanjoku]

Hello, i am new here, i have a problem which to be honest i dont know how to solve it. I have an angular 4 project, which has over 60 components (and this could grow), i also use angular material, when i build using 

ng build --aot --prod --build-optimizer=true

my main.bundle is over 14 mb, which makes the application slow to load, and the angular material loader/dropdowns/input fields always lags, i have reduced my assets folder to just about 1 mb, but my src folder is quite much (because of the the components). i also use a dynamic component to load most of the components, i also use lazy loading, i really do not know how to go about this, and really need some advice/help. Below is my package.json 

"dependencies": {
    "@agm/core": "1.0.0-beta.2",
    "@angular/animations": "5.2.0",
    "@angular/cdk": "5.2.0",
    "@angular/common": "5.2.0",
    "@angular/compiler": "5.2.0",
    "@angular/core": "5.2.0",
    "@angular/flex-layout": "2.0.0-beta.10",
    "@angular/forms": "5.2.0",
    "@angular/http": "5.2.0",
    "@angular/material": "5.2.0",
    "@angular/platform-browser": "5.2.0",
    "@angular/platform-browser-dynamic": "5.2.0",
    "@angular/router": "5.2.0",
    "@angular2-material/icon": "^2.0.0-alpha.8-experimental3",
    "@ng-idle/core": "^2.0.0-beta.15",
    "@ng-idle/keepalive": "^2.0.0-beta.15",
    "@swimlane/ngx-datatable": "11.1.7",
    "angular": "^1.7.0",
    "angular-2-local-storage": "^2.0.0",
    "angular-async-await": "^1.1.2",
    "angular-async-local-storage": "^3.1.4",
    "angular-calendar": "0.21.3",
    "angular-local-storage": "^0.7.1",
    "angular-material-fileupload": "0.0.11",
    "angular-webstorage-service": "^1.0.2",
    "angular2-datatable": "^0.6.0",
    "angular2-moment": "^1.9.0",
    "bootstrap": "3.3.7",
    "bootstrap-material-design": "0.5.10",
    "chart.js": "2.5.0",
    "classlist.js": "1.1.20150312",
    "core-js": "2.4.1",
    "date-fns": "1.28.5",
    "hammerjs": "2.0.8",
    "hopscotch": "0.3.1",
    "linqts": "^1.11.0",
    "material-design-icons": "^3.0.1",
    "ng-mat-search-bar": "^1.0.0-rc.1",
    "ng-material-floating-button": "^0.6.2",
    "ng2-charts": "1.6.0",
    "ng2-dragula": "^1.5.0",
    "ng2-file-upload": "1.2.1",
    "ng2-file-uploader": "^0.1.4",
    "ng2-select": "^2.0.0",
    "ng2-translate": "5.0.0",
    "ng2-validation": "4.2.0",
    "ng4-file-upload": "^5.1.7",
    "ngx-cookie-service": "^1.0.10",
    "ngx-papaparse": "^1.2.5",
    "ngx-quill": "2.0.4",
    "node-sass": "^4.9.0",
    "perfect-scrollbar": "1.3.0",
    "rxjs": "5.5.2",
    "sweetalert2": "^7.22.2",
    "web-animations-js": "2.3.1",
    "zone.js": "0.8.20"
  },

[Sander Elias]

Hi Chikodi,

Given the amount of 3rth party's you are linking in, I'm not surprised. The only thing you can do is make sure you only load the modules that you really need when you need them. Don't put all dependencies in 1 place, but distribute them to the places you actually need them.
Move to angular version 6 will help, and to version 7 (when it becomes available) will help even more.
Search youtube for talks from Minko Gechev, he has a couple on performance and touches this subjet also.

Regards

Sander

[Zlatko Đurić]

14 megs seems way too much. And 60 components shouldn't generate so much output. I mean, look for example angular or material or similar, it doesn't go nowhere close to that.

Yet without seeing your code, one could only speculate. Is your code available online somewhere?

Now, some ideas for how to tackle this. Ranging from regular to... Not regular :) There should be examples online for most of the suggestions, or ask a more specific question if one of the ideas here looks promising to you.

First things first, did you run webpack bundle analyzer to see what takes so much?

For one, you have a lot of deps. Some of them seem to be big and might contribute to the problem. If yes, maybe you can find a smaller replacement. Also, I think there might be some suboptimal coupling in your modules. I mean, if you have lazy routes, you would ideally be able to render a minimal app shell, or even a bigger chunk of an app with a lot less, and later load the heavy dependencies.

Additionally, you might be importing some things that really aren't necessary. E.g. you ave node-sass listed as dep, AFAIK you only use that if you wanna build some sass files, and I assume you don't do that lazily, on the client. But you might have an invalid webpack config that pulls this in.

If nothing else , that's how you could identify better candidates for lazy routes. Then in addition to that, push the lazy chunks through with http2, if you can, you might gain a second or more on preparsing such big bundles.

Additionally, your tree shaking might be a problem, e.g. you could be importing the entirety of one of your deps where a more direct import would do better. Two things might help you there. One is to try to optimize with rollup. That might remove some of the extra code. It might not pick up everything, but it could be just enough to make the app startup time bearable.

Or a bit more on the edge there, you could, as Sander suggests, upgrade to Angular 6. It has some of this tree-shaking built in, but if it's really a problem, try enabling the (still pretty experimental) Angular Ivy compiler and see what happens. Of course, test heavily for bugs, but I think the bundles should go really small.

And by far the most "out there" suggestion I have is, maybe you can offload some of the heavy libs and compile them to Wasm, and only have an angular wrapper for the functionality. That helps in a few ways, splitting up what might be a thick part of the bundle, but also, Wasm has noticably better startup times than regular JavaScript (which is what your bundles are now), and with parsing 14 megs of code, skipping preparsing and other stages in here would definitely be noticable.

Of course, some of these ideas might depend on your target browsers and your skill level and similar. That's why I tried to range them from what I think would be the simplest and most efficient to the silliest that I would love to have to sort out simply because of the challenge :)

Good luck, and let us know how you are progressing!