Large Bundle Size Makes Website Slow

[minhngo3818]

This is an issue when bundling up the frontend folder. In the attached picture, the bundle size is about 1MB which is much larger than recommended size.As a result, our website is slow. Obviously, the demo website performs a bit slow comparing to when running development mode. Switching pages and the animation in resources will show the issue.

There are some solutions for it. One of suggestion is lazy-load or code-splitting techniques, aka import when needed. Other solution is to use vite package to do lazy load with some awesome features (it runs like Flash).

See links below for more information:
React code splitting: https://reactjs.org/docs/code-splitting.html
Vite: https://vitejs.dev/guide/why.html

[jameslindfors]

+1 for vite

A big contributor to the size and speed issues is the npm packages. Here are the bundlephobia results. Some of these packages are already <500kb in size significantly adding to the overall bundle size.

Suggested options to reduce the size (in addition to code-splitting, etc.):

• Explore modifying webpack configurations
  This would take some understanding of how webpack bundles and what optimization options are available. From what I've seen there is not a super straightforward way to modify the config without ejecting. Once ejected, a config folder is created with all webpack configuration files.
• Remove unused or excessively large packages
  The largest package, fakerjs, won't be used in prod so this can either be swapped for hardcoded dummy data or a smaller package and that will reduce the size fairly easily. There are also many css and icon packages so some of those may be redundant. Selecting one icon library and css framework to use for the whole project could remove a bunch of extra dependencies.
• Move dependencies to dev-dependencies
  Packages like @testing-library/react don't need to be a part of the production bundled dependencies so it can be moved to dev-dependencies. It's probably smart to reevaluate all packages and see what can be moved to dev deps.
• Migrate to vite
  Requires ejecting from CRA and webpack. This also requires configuration for the build to minify the build.

I think it's worth it to make changes to the npm packages that are used in the project and then analyze if it's worth it to eject from react-scripts and modify the webpack configuration or to migrate to vite.

[minhngo3818]

I agree, we should try vite in our project. Hopefully, it will reduce significantly bundle size.

Among dependencies, Mui seems to consume a lot of resources. Beside, it causes 9 vulnerabilities. So, there are less benefit to keep it. Some files must be modified by using different package or coding js components

We should choose the most various icon package

Test dependencies probably needs to move to dev-dependencies.

Faker JS is temporarily used in frontend to show dummy. It has a value of generating large chunk of data. Since, we start working in backend, I think should used it in the backend for running test, or adding dummy data. I'm not sure if we can add it into dev-dependencies

[jameslindfors]

I did some testing and migrated to vite. I left all the original dependencies and added two vite npm packages. Already the resource size is 1MB smaller than with react-scripts. I did another test where I removed all the css frameworks, moved testing dependencies to dev, and swapped faker for dummy data and I was able to get the resource size to only 156KB. Small + fast bundles are definitely attainable.

Note - I did have to change all .js files that contained a react component to .jsx for vite to build

Vite Resource Size 2.9.MB - Request Time 14ms

React-Scripts Resource Size 4.0MB - Request Time 30ms

[minhngo3818]

That's a pretty good result after migrating to vite. I'm certain that there is a corruption by removing css frameworks. As we're gonna have people work on our custom css, we probably need to remove most of css frameworks.

I think we can replace icon packages with downloadable icons and use them in <i> tag. Ideally, that won't cost too much memory.