AngularJS bundle tuning forcing me to Angular 5 upgrade

Question

This relates to an AngularJS application, originally built using yo angular-fullstack with JS scripting (not ts). Functionally fine, but hitting performance UX issues.

My production deployment is to AWS ElasticBeanstalk nano instances, which probably isn't helping but I get the impression from reading up that my {app|polyfill|vendor}bundles are too big.

Homework done - biblio and webpack.config.plugins at end.

Even with all of the above plus 'lessons learned' from wiser souls than me (see biblio) included in my project, I'm still seeing 'big' warnings from webpack and large, whole-package bundles in the webpack-bundle-analyzer output:

polyfills.66cd88606235a4586eb1.js.gz    25.8 kB          [emitted]
      app.66cd88606235a4586eb1.js.gz    48.8 kB          [emitted]
   vendor.66cd88606235a4586eb1.js.gz     319 kB          [emitted]  [big]
                ../client/index.html    4.77 kB          [emitted]

I don't think my app is that complicated. 10-ish components on 4 views, one chart (angular-chart.js).

Here are my questions:

1. various modules appear to be bundled whole (e.g. angular 1.23MB, lodash 528KB, ...) For example, I've changed all of my own imports to specific lodash functions/modules, but the overall lodash library is still being bundled. Does that mean that one of my dependencies (or one nested further down is pulling it in, or am I missing something?
2. I think I can change my import module from 'angular'; statements to something more specific like import ... from '@angluar/core'; but all the documentation seems to imply that I'd have to upgrade the whole app to Angular5 to do that - am I missing something? (Said another way, I can't find beginner-friendly documentation on angular2 '@angular/core'.)
3. the angular-cli seems to be for new ng inited projects, so I think it's production shrinking and tree-shaking features aren't available to me unless I upgrade/restructure my project - is that correct?
4. are the bundles that webpack injects into index.html the gzipped ones? Not sure when/how they get used (if at all).
5. I'm configuring and invoking webpack from gulp - are all of the plugins I'm using (see list above) equivalent to the -p CLI option? ...or do I need to do more?
6. Help! What else do I need to look at or do to reduce bundle size? Do I have to go delving in node_modules/** to find out what is sucking in whole packages? What am I missing?

TIA

Biblio

• Angular2 CLI huge vendor bundle: how to improve size for prod? - from which I learned about not importing whole modules when I only need a bit of it (spin-off question above)
• How to use babel loader on node_modules in webpack for ES6+? - from which I learned about setting up a raft of webpack plugins to reduce, organise and compress my bundles (spin-off question above)
• https://hackernoon.com/optimising-your-application-bundle-size-with-webpack-e85b00bab579 - from which I got confirmation from Google that my app is slow because the bundles are big and some more webpack config hints
• https://hackernoon.com/reduce-webpack-bundle-size-for-production-880bb6b2c72f - followed all the steps, but it didn't seem to make any different to my bundle sizes
• https://github.com/mgechev/angular-performance-checklist#introduction - picked as much as I could out of this without going to the 'upgrade to 5' areas.

webpack

My webpack config for production build currently includes:

• config.devtool='source-map'
• DefinePlugin (NODE_ENV=production)
• NoEmitOnErrorsPlugin
• UglifyJsPlugin with everything turned up to 11
• OccurrenceOrderPlugin
• AggressiveMergingPlugin
• CommonsChunkPlugin
• ModuleConcatenationPlugin
• HashedModuleIdsPlugin

Answer 1

OK, so did a raft more delving and think I'm onto some fruitful tools and techniques now. In summary...

• On #1 I went back to a clean, unmodified yo angular-fullstack and it turns out that my bundles weren't much different in size to the ones which came out of the box. So, I don't think that expending loads of effort trying to unpick where I've created bundle size is going to be too fruitful.
• On #2 and #6, I think the answer is technically yes, I could delve into each node_module dependency and 'fix' it from depending on whole bundles, but that seems counter-intuitive for how better coders than I have written those modules in the first place. So, I'm not progressing that.
• On #3, yes I was blurring AngularJSand Angular(5). I want to stay with AngularJS for now so no further action here.
• On #4, no. Manually changing the webpacked index.html to use the gzip bundles results in fast download, but the app doesn't work. Using zipped resources is a web server config thing. Amended my nginx config to serve gzipped js instead - that's just going through deployment as I write.
• On #5, I think so, yes.
• On #6, I found Madge, which helps visualize dependency graphs. Pointing this at my client entry point (client/app/app.js in my case) and including node_modules (see CLI options) suggests:
  • I need to look at structuring my single module into a series of modules so each can be loaded seperately
  • I need to look at lazy loading of modules which are not required for the home page (example)[https://toddmotto.com/lazy-loading-angular-code-splitting-webpack]
• Further tuning needs to come from optimizing functional design of the home page so it is light on both number http requests and size of responses. Nothing earth-shatteringly insightful there, it just hadn't shown up on local dev environment so I hadn't thought about it until now.