Increased initial main.js bundle size in v9 - mainly due to @angular/material packages

[bri1990]

🐞 Bug report

Command (mark with an x)

• new
• build
• serve
• test
• e2e
• generate
• add
• update
• lint
• xi18n
• run
• config
• help
• version
• doc

Is this a regression?

yes,

Description

Our initial bundle increased after the upgrade to angular v9. Below 2 screenshots made with webpack-bundle-analyzer, both are build with the --prod tag on. The complete size of our app decreased in size, but the main bundle increased slightly.

reporting this
@filipesilva who mentioned the following

If you see your bundles increasing in size with Ivy, we want to know. Please open a new issue with a reproduction if possible. If you can’t publicly share your reproduction, consider sharing it privately instead.

In our case the initial bundle from the @angular module in angular 9.0.0 is increased by 170 kb (parsed) compared to the build size in angular 8.3.20

ANGULAR 9.0.0 bundle overview

ANGULAR 8.3.20 bundle overview

🔬 Minimal Reproduction

its a private repo, but can share an bitbucket account via a private message if needed

🔥 Exception or Error

budle size difference

Angular 9:

chunk {33} polyfills-es2015.5bbe6128ce574187632a.js (polyfills) 97.3 kB [initial] [rendered]
chunk {34} polyfills-es5.7489d086305aa2ccf313.js (polyfills-es5) 188 kB [initial] [rendered]
--
chunk {18} runtime-es2015.7b3c2daa7eda967f9d4b.js (runtime) 4.55 kB [entry] [rendered]
chunk {18} runtime-es5.7b3c2daa7eda967f9d4b.js (runtime) 4.54 kB [entry] [rendered]
--
chunk {32} main-es2015.7771c8f8f77604a6a0fb.js (main) 1.13 MB [initial] [rendered]
chunk {32} main-es5.7771c8f8f77604a6a0fb.js (main) 1.32 MB [initial] [rendered]
--
chunk {35} styles.96f30aa09bf98d520a7b.css (styles) 403 kB [initial] [rendered]

Angular 8:

chunk {20} runtime-es2015.8dcc6cc63434c93fc456.js (runtime) 4.68 kB [entry] [rendered]
chunk {20} runtime-es5.8dcc6cc63434c93fc456.js (runtime) 4.67 kB [entry] [rendered]
--
chunk {40} polyfills-es2015.c6262141f4f874e78e85.js (polyfills) 98.1 kB [initial] [rendered]
chunk {41} polyfills-es5.468b140bd31c7a429390.js (polyfills-es5) 185 kB [initial] [rendered]
--
chunk {39} main-es2015.d68e6e1b9429135d5faf.js (main) 1.02 MB [initial] [rendered]
chunk {39} main-es5.d68e6e1b9429135d5faf.js (main) 1.19 MB [initial] [rendered]
--
chunk {42} styles.38056460a1b2b723be01.css (styles) 397 kB [initial] [rendered]

🌍 Your Environment

ngular CLI: 9.0.0
Node: 13.3.0
OS: darwin x64

Angular: 9.0.0
... animations, cdk, cli, common, compiler, compiler-cli, core
... forms, language-service, material, platform-browser
... platform-browser-dynamic, router
Ivy Workspace: Yes

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.900.0
@angular-devkit/build-angular     0.900.0
@angular-devkit/build-optimizer   0.900.0
@angular-devkit/build-webpack     0.900.0
@angular-devkit/core              9.0.0
@angular-devkit/schematics        9.0.0
@angular/flex-layout              9.0.0-beta.28
@ngtools/webpack                  9.0.0
@schematics/angular               9.0.0
@schematics/update                0.900.0
rxjs                              6.5.4
typescript                        3.7.5
webpack                           4.41.5

Anything else relevant?

Similar issues: angular/angular-cli#16989

[filipesilva]

Heya, thanks for the report!

The current situations we know this might happen in are documented in https://angular.io/guide/ivy-compatibility#payload-size-debugging. Can you take a look at case 1. and 2. just in case they apply in your case?

I'd like to take a look at your project if possible. I think the most straightforward way to share it would be a private github repo (these are now free) that you invite me to. Would that work?

[bri1990]

@filipesilva
Ok done, I had a look last night at the debugging post, will have another look later today. In the meantime I gave you access to the private repo

[filipesilva]

@bri1990 looking at the project at the moment. Can you tell me in which of the apps you saw the increased bundle size?

Since you have two apps and many shared libraries, I think you are suffering from case 2 in https://angular.io/guide/ivy-compatibility#payload-size-debugging. Can you try the approach described in angular/angular-cli#16799 (comment) and see if it works please?

[bri1990]

@filipesilva in the edu-app, it uses both the @education as the @banax folder (ng build --prod --project edu-app, we currently only use that one in that repo),

Can you try the approach described in angular/angular-cli#16799 (comment) and see if it works please?
Ok I'm going to have a look. To explain the our repo a little you see multiple libraries but these only contain style sheets and components that are loaded into our main app

Regarding case 2:
I added "sideEffects": false to the main package.json (we only have one in the repo you have access), this resulted in a 0.05mb decrease in our main bundle ++

this gets us very close to the v8 build size

[filipesilva]

It's not a great idea to add it in the main toplevel one, because your apps do have at least side effects in main.ts. It's better to add it in the library roots. If the library doesn't actually have a package.json, you can add one with just {"sideEffects": false}.

[filipesilva]

I tried putting these various package.json and saw a main bundle of 1.09 MB, which is still larger than the 1.02 MB with View Engine. I've got to dig a bit deeper.

[bri1990]

Hi @filipesilva, thanks for the hint! will implement it.

I hope you are able to spot the problem:)

I must admit, I expected angular v9 to reduce the initial load by quite a bit. Are we doing something wrong here? I've seen some examples elsewhere but the initial load remained the same in most cases (examples were done in 9.R.C)

In our case we have quite a large css bundle, I believe 160 kb is for theming alone (dark + normal modus), so some room to improve here.

gr

[bri1990]

@filipesilva using "sideEffects": false is causing some problems for us when serving the angular app after building (via nginx hosting it on google cloud platform). We are still figuring out why this is happening

perhaps it is use full information

[bri1990]

another question is, do you still need access to the repo?

[filipesilva]

@bri1990 are you only seeing the problems when serving on nginx and not on ng serve? If so, it might be a caching issue.

I still need access to the repo because I wanted to find the reason for the size difference. But I also have it on disk from the initial investigation so you can remove my access and I will ask it again if relevant.

[bri1990]

Hi again @filipesilva, no it only happends on nginx, ng serve runs fine. We find it quite hard to debug, so we removed the "sideEffects": false lines for now

I still need access to the repo because I wanted to find the reason for the size difference. But I also have it on disk from the initial investigation so you can remove my access and I will ask it again if relevant.
That is fine! was just wondering, hope you find the problem. I won't remove your access

Will post our findings regarding the nginx problem here

[filipesilva]

Was taking a look today again, and one of the things I tried was to make builds without lazy routes. This way we can see bundle sizes without the de-optimizations that can result with lazy routes.

With Ivy the main bundle was 831296 B. With VE it was 814688 B. So even without lazy routes Ivy makes your bundle larger, which I find surprising.

I made my builds with source maps so I could use source-map-explorer to figure out where the extra size came from. Notably, in Ivy the source maps say 715 KB come from node_modules but in VE it's only 606 KB. Within node_modules, Ivy has 526 KB from @angular/* directories while VE has only 428 KB. And of the angular packages, the Ivy bundle has 126 KB from @angular/material while the VE one only has 55 KB. So looking at @angular/material seemed promising.

The Ivy sourcemaps for material looked like this:

And the VE ones:

This looks quite odd to me. The Ivy app seems to have a lot more code from Ivy. list.js is especially striking, since it's 29kb in Ivy but only 1kb in VE. I double checked and your app is using the correct deep imports (e.g. @angular/material/list). But I also find it weird that I can't see any .ngfactory.js file in these source maps, and I used to see these before.

I ran ng build edu-app --prod --verbose &> log.txt to see the verbose log for both Ive and VE. The VE log mentions the .ngfactory.js files there for material so at least that confirms they were used.

At this point I feel I'm kinda out of leads so I might as well just go though the verbose log to see if something catches my eyes. I've seen a bunch of these in the past so that's a reasonable enough thing to do.

I did find something odd early on:

 [1hPV] D:/sandbox/banax_angular/node_modules/rxjs/internal/Subscriber.js 9.17 KiB {1} [built]
     ModuleConcatenation bailout: Module is not an ECMAScript module
     cjs require ../Subscriber [JJ8B] D:/sandbox/banax_angular/node_modules/rxjs/internal/util/canReportError.js 3:33-57
     cjs require ../Subscriber [Yfti] D:/sandbox/banax_angular/node_modules/rxjs/internal/util/toSubscriber.js 3:33-57
     cjs require ./Subscriber [d4zx] D:/sandbox/banax_angular/node_modules/rxjs/internal/InnerSubscriber.js 18:33-56
     cjs require ./Subscriber [dmvN] D:/sandbox/banax_angular/node_modules/rxjs/internal/OuterSubscriber.js 18:33-56
     cjs require ../Subscriber [sGav] D:/sandbox/banax_angular/node_modules/rxjs/internal/operators/observeOn.js 18:33-57
     cjs require ./Subscriber [tkgy] D:/sandbox/banax_angular/node_modules/rxjs/internal/Subject.js 19:33-56

This is the entry for the D:/sandbox/banax_angular/node_modules/rxjs/internal/Subscriber.js module. It says why this module is in the compilation, and why it's not concatenated with other modules. Module concatenation is a big part of size savings so it's important to have as little of these ModuleConcatenation bailout as possible.

I saw this ModuleConcatenation bailout: Module is not an ECMAScript module for a bunch of rxjs modules. But since I know that RxJS does ship a ESM version, I find it odd. I searched the project source code for rxjs/ and found a bunch of import { Subject } from 'rxjs/internal/Subject'; and the like.

Projects really shouldn't be importing from rxjs/internal so this looks wrong. I also saw a tslint rule blacklisting rxjs and found that odd, since that is the correct way of importing things like Subject. Maybe at some point we made projects with that lint rule and since then removed it?

I replaced all rx/internal/operators/* imports to rx/operators, and all remaining rx/internal/* ones to just rxjs. I rebuilt and saw the Ivy main down to 799681 B (from 831296) and the VE one down to 783077 B (from 814688). Keep in mind these are still numbers for the app without any lazy routes. So about 31kB down in both. This wasn't the cause of the Ivy vs VE problem but it was something that was going wrong regardless.

[filipesilva]

Still looking at the verbose log, I remove the terser logs at the end and use VSCode's "fold all" functionality to fold log bits. It seems to recognize the boundaries pretty well.

The Ivy listing for modules in main.js looks like this:

The Ivy one:

Nothing super odd here. A bunch of little modules related to sockets and whatnot, that seem to be commonjs modules, and then a gigantic concatenated main-edu.ts module. They even match line numbers. This looks right.

[filipesilva]

Earlier it occurred to me, and meanwhile I forgot, that that might be unused code in the app folder itself, so I also added {"sideEffects": false} in projects/edu-app/src/app/package.json. It can't be in projects/edu-app/src because main.ts does have side effects. I tried that now, but no change. Still 799681 B.