x)
I am using angular 8.3.20, when i build my appplication it show my bundle size with 1.5mb refer below image:

But when i use build analyzer to check my bundle size it shows 4mb:

Download below sample
ang_schedule_sample.zip
give npm i
then take build ng build
use webpack bundle analyzer
https://coryrylan.com/blog/analyzing-bundle-size-with-the-angular-cli-and-webpack
"@angular/animations": "~8.2.14",
"@angular/common": "~8.2.14",
"@angular/compiler": "~8.2.14",
"@angular/core": "~8.2.14",
"@angular/forms": "~8.2.14",
"@angular/platform-browser": "~8.2.14",
"@angular/platform-browser-dynamic": "~8.2.14",
"@angular/router": "~8.2.14",
"@angular-devkit/build-angular": "~0.803.20",
"@angular/cli": "~8.3.20",
"@angular/compiler-cli": "~8.2.14",
"@angular/language-service": "~8.2.14",
Anything else relevant?
Is this behavior of bundle analyzer or something?
But when i use target as es5it only generates main.es5.js so webpack bundle analyzer shows less size

Sourcemap Explorer (https://github.com/danvk/source-map-explorer#readme) is generally a better option to analyze the application. It will use the generated application files within its analysis which will ensure the values shown reflect the on-disk sizes. Enabling source maps for the build is, however, required.
For context, this happens because webpack bundle analyzer will read stats.json, which only contains information about the webpack compilation. But since we do other processing outside the webpack compilation, that is not accurate anymore.
We don't really plan to move all processing to within webpack so the correct approach is probably to deprecate the --stats-json flag as it can't provide accurate results anymore.
@filipesilva , are you guys going to remove this support for angular?
Talked to @IgorMinar about this. He argued that bundle analyzer is still useful to identify fragmentation between bundles. Even if the numbers are bogus there is still useful chunk information which can be hard to glean from sourcemap explorer.
I believe we already state somewhere in our docs to prefer sourcemap explorer. We should additionally add in the docs somewhere what the intended usage of bundle analyzer is and explicitly state that these numbers are wrong, pointing the user to sourcemap explorer for those use cases.
However, the output of bundle analyzer is extremely confusing and users who try it out would have no reason to believe the numbers are inaccurate. I'm thinking we should also add a warning to --stats-json stating that the numbers are not accurate and redirect users to the relevant documentation.
This seems to be mostly a documentation problem. I'll follow up with some folks there.
Talked to some folks on the docs side of things. It seems we're generally missing docs covering application performance, where it would make sense to discuss bundle-analyzer and sourcemap explorer. These docs will be added in this issue.
Once that happens, we'll revisit this issue and add a warning in the CLI when --stats-json is used, pointing users to that doc.
Most helpful comment
For context, this happens because webpack bundle analyzer will read
stats.json, which only contains information about the webpack compilation. But since we do other processing outside the webpack compilation, that is not accurate anymore.We don't really plan to move all processing to within webpack so the correct approach is probably to deprecate the
--stats-jsonflag as it can't provide accurate results anymore.