Lazy Loading + Bundle Size Optimization overview

[mikhael28]

Prior to launching the open-source project, I took steps to optimize a few things - including the bundle size. After I took a look at the npm modules using the source-map-explorer, I optimized a few libraries using efficient tree shaking, took out a few modules that were adding unnecessary burden (which resulted in the creation of the admin-console) and a few other things. As a result, the bundle size (after gzip, of course) is reasonable. After running npm run build, here is the CRA report.

Then, we can run the npm script npm run analyze to use the source-map-explorer, we can see that the total bundle size is 2.86 mb in total. A bit big, but frankly not outside the insane bundle size that node_modules foist upon us. As far as I know, CRA already 'uglifies' the code for us.

A big headache for us here is the quill.js - 250kb is by far the biggest dependency. Perhaps we should replace that, recommendations welcome.

Then comes the react core files themselves, which we obviously need. Then comes victory charts, which I don't want to replace (they are Seattle based, courtesy of Formidable) and we are only using them in a slight capacity. There is a lot more value we can get from them, and I want to see what that bundle size looks like then.

So, after that, looking at how else we can decrease our initial bundle size - we can look at lazy loading. The components with quill.js/the rich text editor replacement for it, and the components involving victory charts are prime candidates to shave off a bit of the file size.

Outside of that, what else can we add to the discussion?

[wesley3295]

So I replaced react-bootstrap 3 with react-bootstrap 5 the new KB is 861.46. I'm guessing this isn't ideal for this project?

[mikhael28]

Would you please send a link to the npm repositories you are talking about? I'm only familiar with react-bootstrap 0.32 and 1.6 - which has huge breaking changes between the two versions and are backwards incompatible. Would you also post a screenshot of the new package.json so I could see the new packages/versions?

In general, we don't want to add another 100kb just to add one component. We want to keep our bundle low. We do want to migrate from react-bootstrap at some point though, but that's a big endeavor. Modals and forms stands out in my mind as pretty deeply embedded.

[wesley3295]

https://react-bootstrap.github.io/

[mikhael28]

To clarify, you only want to use the 'Typeahead' component? Is there an npm package somewhere with like 10kb that we can use instead? Or, we can use the datalist native HTML search. I do not want to add 100kb for just one component. I'm also hesitant to use a beta release of a module, when there is a stable 1.6 release.

As an update to the Quill.js 250kb package, I found a npm module called Pell which is a WYSISWYG rich text editor with only 4kb. https://bestofjs.org/projects/pell
That should save us 200kb plus on our bundle size.

[mikhael28]

An item to investigate - is AWS Amplify serving GZipped distribution files? I don't think so. Should check if that's even possible, likely should be but I may need to change build instructions. Might possibly need custom docker image, but unlikely.

[mikhael28]

@akashshyamdev check this issue out, if you haven't already. React-bootstrap only taking up 31kb due to lazy loading, very efficient! Material UI taking up 91kb, and that's without using their form library either.

[akashshyamdev]

Great @mikhael28 , so why don't we eliminate the use of MUI altogether? Just stick with react bootstrap and use custom components when the componentWillReceiveProps is used.

[mikhael28]

The point that I want to make, is that we don't need to 'limit' ourselves to UI components from one library. We can always just pick and choose what we want - for example, we are using MUI for the bottom navigation. If we stopped using material, then we would have to figure out replacements for that component, among others. There is no benefit to sticking with one, and only one, library. Especially when we can tree shake components and only use what we want.

[akashshyamdev]

Hmm, makes sense @mikhael28 👍

[vmcodes]

Hi @mikhael28 I just have a simple PR I'd like to make related to this issue and potentially get more involved in the project. I've read through the contributing documentation, but was wondering if I need to be added as a contributor to submit the PR or if I should just fork the repo. This is what I found after lazy loading the routes.

[mikhael28]

Hi @vmcodes - please fork the repository and submit a PR to the upstream repository! That is a very solid improvement in the initial chunk's bundle size - when I was updating the npm dependencies today and ran the build command, I noticed that the main.js was around 640kb or something like that. When you saw you are lazy loading the routes, do you mean you are lazy loading all of them, as in some HoC/logic in React Router? Or are you dynamically importing components in another way?

[mikhael28]

I updated a good amount of code/package.json/yarn.lock dependencies today, so definitely make sure to fork the repository/pull from main before submitting a PR.

[vmcodes]

Thanks @mikhael28. I just lazy loaded the components used in Route.js, if you think that's a valid improvement then I'll fork the repo and make the PR.

[mikhael28]

Very valid improvement! Please send a PR, it's a great 200kb improvement. Especially since we want to have ParetOS accessible in areas with slower internet, having the smallest bundle possible should be our goal. Please reference this issue in the PR :D

[mikhael28]

@vmcodes excellent work reducing the bundle size of the main.js.bundle by 200kb! That is fantastic - I also didn't notice any lazy loading Suspense indicators when running the app, but then again I am running a brand new 14' M1 MacBook Pro. My ish fast. So, maybe I should buy a Chromebook to do some testing of how the app performs on lesser hardware.

Either way, I am going to go ahead and close this ticket! The work that @vmcodes did was great, and I've gone ahead and removed quill.js proactively - I'm going to implement Pell myself, and that will save us quite some space (5kb vs 200kb). Bundle size optimization will be a continuous process, and I would like us to keep this issue in mind as well move forward.

[mikhael28]

I've gone ahead and pinned the Issue, so we can easily reference back to it in the future.