vendor.bundle.js size is around 10 MB

[jayakrishna-v]

ng -v 1.5.4
node -v 6.11.2
npm -v 3.10.10

Observed behavior

We have an application with more than 7 modules. When we build this application we are getting vendor.bundle.js file of size 9.95 MB. This will have an impact on performance. Can someone explain the reason fro this and how to reduce the size of build files.

Desired behavior

Expecting lesser size for bundle files

[jgodi]

What command did you run to get these results?

ng build by itself does not have any optimizations. If you ng build --help you can see all the flags you can pass to further optimize your code and reduce the output sizes.

Try ng build -prod -aot -vc -cc -dop --buildOptimizer and see what your numbers are. This will enable production mode, use AOT, use a vendor chunk for third party libs, pull all common code out into a common chunk, make sure the output path is clean and lastly use the @angular-devkit/build-optimizer for further optimizations.

If that is still large, then do a run through in your application for third-party libraries that you are using. (1) Are you importing the entire RxJS library? (2) Moment with all localizations? etc..

[clydin]

With the latest CLI, --prod includes the aforementioned options with the exception of the vendor chunk option. With AOT and the build optimizer enabled, not using a vendor chunk is typically more beneficial as it allows additional optimizations and a resulting further size reduction.

[filipesilva]

Closing as answered by @jgodi and @clydin, thanks!

[jayakrishna-v]

Thanks for the detailed explanation @jgodi and @clydin, Thanks. I tried to run the command as mentioned but getting below error. Although the size of the bundles are too low as expected, Im trying to figure out this issue. I hope you are aware of this issue related to ngfactory. Your help in resolving this issue will be most appreciated. Thanks.

[jayakrishna-v]

@filipesilva @jgodi @clydin
I have referred to the closed issue #7925. My main.ts is already importing AppModule as mentioned by @jinder But still getting this error.

My main.ts looks as below:

import { enableProdMode } from '@angular/core';
import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';

import { AppModule } from './app/app.module';
import { environment } from './environments/environment';
import 'hammerjs';

if (environment.production) {
enableProdMode();
}

platformBrowserDynamic().bootstrapModule(AppModule)
.catch(err => console.log(err));

[valentinoPereira]

jgodi saved my day!!!!!!!!!!!!!!!!

What a solution.. Thanks man. It worked.

It got my site content from 11BMB to 1MB.. Plus using lazy loaded modules makes load faster

[FrancescoBorzi]

I got the same issue using Angular CLI 6.1.3. My vendor.js is 7.50 MB and if I enable --aot it's even bigger, becoming almost 10 MB.

[danielmhair]

Same issue here. I tried the defaults in angular.json for production, and then also tried this:

              "optimization": true,
              "outputHashing": "all",
              "sourceMap": false,
              "extractCss": true,
              "namedChunks": true,
              "aot": true,
              "extractLicenses": true,
              "vendorChunk": true,
              "commonChunk": true,
              "buildOptimizer": true

I'm on Angular 6.0.9. My vendor.js is 4.69 MB when I run ng build --prod

When running webpack-bundle-analyzer, it shows what is taking the most and @angular/* is using about 3MB

[clydin]

@danielmhair The size of the rectangle represents the percentage of the total size within the bundle. Both faker and @progress are larger than @angular. The stat size is the original size of the module on disk before bundling; the relevant number is really gzip size as this is the one that represents the actual data that will be transfered. Also, Parsed size is the size of the module within the uncompressed bundle. Note that Material is included under the @angular block and is roughly a third of that size.
Overall, usage of large (either in quantity or size) third-party modules will result in large bundle sizes. To optimize initial loading time, it is recommended to use lazy loaded routes and only import dependencies within the routes that require their use.

[danielmhair]

I understand that. And your right that the parsed size is smaller. I forgot to mention that. Thanks for reminding me, but its still about 1 MB. Prior to Angular 6, our entire size came to 1.5 MB. That included all of these packages (@progress, faker, @angular and everything else). I understand that faker is large and I'm working on getting that smaller, but I was focusing on @angular for this issue. It was claimed that with AOT compiling, @angular would be 250kb. I understand that I am using @angular/material and that wouldn't be considered in that size. But that means without @angular/material, the parsed size is ~600kb. That is a lot more than 250kb. We do use lazy loading, but due to the Angular 6 update, there is a bug that is forcing us out of lazy loading, but that is another issue we are working to resolve.

But here is my main purpose: I'm messaging in here to figure out how to lower the size to where it was before the update to Angular 6. That's a much bigger size that it was before. All we did was update packages like rxjs and the main packages that required us to update to their Angular 6 version. Now writing this out though, I think your right, in that perhaps its @progress and faker that I need to worry about the most. I did have to update @progress to their Angular 6 package, so maybe their package increased by then.

Thanks for your info.

[clydin]

The gzipped size (which represents the actual client transfer size) is less then 250kb. This is with material, cdk, animations, and forms (which together appears to be two thirds of that size). Also important to note is that the new renderer currently under development will reduce sizes even further.

Some areas that should be investigated is the inclusion of locales within fake and oidc-client. Both appear to be including all available locales which appear to be the largest component of the overall size. The kendo grid also appears to be fairly large but that may be unavoidable.

[danielmhair]

Yeah, for sure. Thanks for your thoughts @clydin. I'm planning to remove the locales from faker already. Sadly enough, I only use like four pieces of faker, which actually is about 10-30kb, so its not tree-shaking at all. I didn't realize that about oidc-client, actually. Thanks.