Develop Reference

When to code split (React- Suspense and Lazy)

What bundle size in KB should I consider splitting at? At what point does weight become too heavy that I should split it out. My whole bundle without splitting is around 800KB so it loads relatively fast. I am just trying to figure out if it should be around 10KB/ 100KB, etc... Moment.js takes around 50KB, so I am trying to figure out if I should split out all modules that contain moment for example.
If I don't code split does that mean overall it provides a better user experience once they load the initial page since every other page would load faster? I get this would lead to a bad first experience of loading the page, but am just trying to figure out the tradeoffs.
Haven't found any good resources with this information. I am using create react app.

800kb is not super big but still, the smaller your bundle is, the better.
I think the main problem having only one bundle is that, if you change one single character in your app, all your clients will need to download everything again.
Let's take an example:
You see a typo in your code. You already have thousands of users who downloaded the 800kb bundle with this typo.
You push a fix (only one character change).
All your users need to download the whole bundle again (yes, they need to download Moment.js again). Be it 1*800kb or 8*100kb, they will still need to download 800kb of data. (related question)
What you want to do, is to split your chunks in a way that allows users to only download the files that changed. For the other files, they can be cached, so no need to download them again. So in the example above, you don't want your users to download Moment.js again because... it didn't change at all.
I suggest you to read this very nice article about how to split your bundle:
https://medium.com/hackernoon/the-100-correct-way-to-split-your-chunks-with-webpack-f8a9df5b7758
You can also add one level of split by creating "per page" chunks. Here is how to do it with React: https://reactjs.org/docs/code-splitting.html
If you make changes on Page A, your users won't have to download the chunks for Page B again.

How to minify vendor.js on ng serve

I am currently about to embark on a redesign. This requires many scss changes and reloading the website. I would like to take advantage of the ng nerve command that uses live reload.
Does anyone know how I can run the ng serve and have the vendor.js file minified? When I use ng serve --prod it minifies the vendor.js... but it takes 10-15 seconds to build it.
Currently my vendor.js file is 8.9mb unminified and it's taking 2-3 seconds reach reload in development.
Anyone have ideas?
ng serve --prod while it does to minification, takes 2-3 minutes each time.
Note: Currently using Angular 6.X

I had observed the recompilation of angular projects using ng serve with Visual Studio Code. Vendor.js is not recompiled when you make changes to the project. It is only compiled during the first execution of ng serve.
If you wish to improve compile speed in development mode, you might want to consider implementing lazy loading. If lazy loading is implemented, whenever you make changes to a component, only that component's module is recompiled. This can greatly save compilation time in the long run.
This had happened to me in one of my first Angular projects (a school assignment). To cut the long story short, I had read about lazy-loading, implemented it to the admin dashboard module, but my friend refused to implement it to the user module because he would had to shift a lot of code around and restructure the project. As the project became bigger... it became evident how important lazy-loading can be...
First compilation: (I will explain a bit) manage-* modules are feature modules belonging to the admin module. Every component in the user-module: sidebar, navbar, filter, search, etc, all belongs to the user module, hence it's significantly larger, 3.46MB compared to admin and it's feature modules.
E.g. Commenting 3 lines of html in one of the component in user module recompiles the entire user-module and takes 5523ms. If I am running photoshop, or other memory intensive programs, it'd take much much longer!
E.g. Commenting 3 lines of html and recompiling a feature module in admin dashboard module takes < 1s:
I am still new to Angular but lesson learnt: do lazy-loading, it does saves user's bandwidth and your development time =]

The solution to your problem isn't exactly what you think it is, this is a common problem across all front-end frameworks and webpack builds.
Webpack provides an elegant solution to handle this. It's called hot module replacement. I.e. webpack will change your code and styles on the fly without requiring to reload the page. Angular needs a bit of customisation to set this up which is outlined step by step here.
https://github.com/angular/angular-cli/blob/master/docs/documentation/stories/configure-hmr.md

I think you are facing this issue in the wrong way.
I understand you are redesigning an angular app and using ng serve to see your work realtime in the browser, but you are suffering of slow build time as vendor.js is rebuilt on each change.
The problem is not that vendor.js is big (always is) but that is been built on each change. As other answers mentioned, changes on application code should not (usually) trigger the rebuild of vendor.js. This indicates another problem, probably you are messing something with scss imports.
Also, using ng serve --prod probably won't solve your problem at all. Build times are higher than non optimized builds and I don't think you problem was solved by minifying code (Again your problem is on the build time).
In any case, if you want to go ahead with your original question and run the ng serve and have the vendor.js file minified, you will need to create a custom webpack configuration, have a look on these sites:
https://dev.to/meltedspark/customizing-angular-cli-6-buildan-alternative-to-ng-eject-1oc4
https://angular-guru.com/blog/angular-webpack
In this last site, you can find the webpack configuration which corresponds to vendor.js
Hope this helps, I would need more details to provide a better answer.

Firstly, why do you need it so badly? Yes, vendor.js will not be minified, but it will not be re-compiled on SCSS/view-level changes either, right?
So, at the end of the exercise, the advantage you are going to receive is only about first-time loading a ~2MiB file vs an 8.9MiB file, which would be marginal since you can choose to enable the browser's BFcache (by NOT checking "Disable cache" under DevTools>Network)
If you must do it, I guess an approach would be to go with Hot Module Replacement for the Component's module you would be working on.
EDIT:
Personally, I find too many reloads for small visual HTML/CSS changes an overkill. Sometimes I "Inspect" the elements, and change the HTML/CSS via devTools and copy the HTML/CSS to a temp place. Then I make those 5-6 changes to the Components and save and reload to verify.
It's always a better practice to "Inspect" element and make the visual changes (like minor CSS style changes) and check how it looks then and there, instead of making those changes in your real code and waiting for a whole re-build cycle just to see a minor CSS change.

You can use lazy loading in your app to reduce the bundle size . It also increases the speed of the application .

Advantage of using lazyload?

So i stumble on this component called lazyload.
What does it do and advantage and disadvantage of using it ??
Just curious about it because i watch some of john papa's videos and he keep mentioning it.

They idea of lazy load is that you only load something when you need it.
For example: at startup of your application you might not need a library to validate your form fields. (you only need it when someone actualy fills in a form and submits it).
Lazy loading makes sure its only loaded when needed.
The Plus:
Reduced start/load times & size.
Packages/data that are not used by the current user, will not be loaded.
Minus:
You have to have more seperate packages you can't minify and bundle them together.
More request to the server (because you can't bundle them).
could have a load on first use experience, the first time user does something the application needs to load some extra stuff.
conclusion & advice
So consider the size and the lifecycle of your application. If the application is small and you package all in one. probably the simplest approach would be to package everything in one. it's a bit of a longer load time, but after that the javascript gets cached in the browser anyways so it doesn't matter after first load.
Reasons you want to lazy load:
You want to be able to update seperate parts of the applications (thus not bundle it)
Application becoming problematically big. you want to cut it up in smaller parts.
You don't bundle your javascript files (great example here before angular was requirejs).
You have a lot of different types of users using the system each with completely different set of scripts.
Every page uses completely different set of javascript. (not likely when you use angular)

Split very large javascript file

I'm working on a web project that uses webgl content generated with unity. When trying to load the required js files the browser freezes for around 30 seconds. The main js file has 35MB size unzipped so this seems to be the cause.
I want to avoid this freeze if possible but I couldn't manage to do it using WebWorkers since the script needs access to UI. My other possible solution is to try to split the js file into smaller ones but I don't know how to do it. Do you have any suggestions?

If you add async to your script tag like this <script async src="app.min.js"></script> it will not block rendering anymore. Also caching the script in the browser or delivering it from a CDN can help reduce the download time.
35MB are, however, way too much for a website. Are you sure there isn't a lot of unused stuff like libraries in it?
We recently wrote an article with web performance best practices, with explanations to critical rendering path and other fronted concerns here

35 MB just for the JS file seems ridiculous. It could be that the entire build is probably of that size (textures, media, etc.). Have a look here on how to reduce the build size.

Though 35 MB is wayyyy to much for a JS file, you can start by following pointers:
Create utilities and reuse the code. This can be at any level. Be it generic component (HTML generating code) or validation logic, if it can be configured using arguments, make a function and use it.
If you have Hard-coded JSON in your js, move them to .josn files and load them only when they are required.
Split files based on sections in view. In SPAs, there are cases when a section is not visible. For such cases, don't load such files. Spread your code base from 1 file to 100s of file.
If you have a lot of event listeners, move them to different file. You can have section_event.js, section_data.json, section_utils.js and section_index.js. If there involves lot of data parsing, you can even have section_parser.js
Basic Idea is to split code into multiple files. Then, make code more reusable. You can even look into loading libraries to reduce your load.
Also, load a resource only when required. SPA have stages. Load concerned files when they are needed. Split download from 1 time to partial, on-demand approach. Also look into webpack or grunt or gulp to minify js.

Angular 2 page size

I am just getting started with Angular 2. It actually makes me think about the size of the page just for the Hello World.
Please look at the scripts which were actually needed and it already is 1.75 MB.
Offcourse with minification it would reduce 30-35% approximately.
Yet it would still be above 1 MB just for this junk Hello World type application. Adding bootstrap CSS / Jquery / Jquery UI at the minimal would take it even further plus add images depending upon the web application type.
Question is 1.75 MB of script without writing a single line of code pertaining to the application.
Is this the new web standard to make the page size on an average above 4-5 MB?

There are several strategies that will reduce the total size of your site.
Enable gzip compression for your assets. Most text files (like JS files) compress very well due to lots of strings that get repeated.
Use the minimised versions of libraries, as you identified.
Use CDN references to 3rd party libraries if possible. That way, the user may already have the file in their cache and don't need to refetch it. Some CDNs also support HTTP/2, meaning that more files can be requested in parallel.
Take advantage of the Ahead-Of-Time compilation (AOT, a.k.a. offline compilation) in Angular 2 RC 5, and swap to using the version of Angular 2 without the compiler. That saves about half of the size of the Angular 2 library file.
Use HTTP/2 yourself for your assets, and refer to each JS file individually, rather than bundling it. That way, if they haven't changed, the user won't need to download them again when they reload. And the first time, all the files can be fetched in parallel.
Use conditional comments or server side processing to remove the shims and other JS files that are only relevant to certain browsers like IE. That way, other browsers don't download those useless scripts.
Use something like Rollup or another tool that can do "tree shaking" to remove unused code.
There are probably other ways to save even more, but this is a good starting point.

Angular2 is going to get smaller in smaller now. See ngconf about this. Its mainly result of tree-shaking minification (loading only code, that really used).
Angular 2 seed project, wich in prod build loads with ~300kb is already available for use.