[Bug]: Clicking on the first plan takes a long time to load

[ZzRanger]

What did you expect to happen?

I expect the degree planning tool to immediately load after clicking on a plan.

What happened?

Version

Beta 0.1.0

What browsers are you seeing the problem on?

No response

Relevant log output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[akevinge]

For some reason the response is 4MB compressed and 40MB decompressed.

The production builds are completely fine. I ran this analyzer on the build, and the bundle size is completely normal. Compressed bundle size on the server is about 100KB and on the client is 500KB.

The issue seems to be that MUI isn't being tree-shaken for some reason (see .next/trace). Seems there are many top-level imports for @mui/material and @mui/icons-material throughout the code, so that's probably why.

[ZzRanger]

Nice analysis! This is something we would like to optimize sometime in the future. If you are interested in working on this let me know and I can assign this to you.

[akevinge]

hey @ZzRanger,

I wouldn't mind working on this issue.

If it is an issue of top-level imports, I'm not really sure why it doesn't occur in production build. I would imagine tree-shaking would be the same for production and development, but I honestly don't know what the default configuration is. I didn't look that closely, but maybe the production build is just as unoptimized but the compression hides any noticeable lag? I'll look into it.

Side note: I just realized that 500KB is also pretty big

[ZzRanger]

Per discussion at 9/20 meeting, we'll be tabling this issue for now.

[ZzRanger]

Linking #118 #156 and by extension #216, as we can look to optimize loading time of Credits page as well. I have some intuition on how to do it (potentially load components after initial page load through some useEffect magic) but will need further discussion.

[akevinge]

So after taking a good look at the bundle size, there are 3 culprits of the large bundle size.

Redux looks really big, but it's actually its usage of Firebase which is discussed later.

courses.json

This file is really huge. We could get rid of it and use Next's API routes or a Firebase cloud function instead. Not sure if the latency of the request is better than loading it in the bundle, but we could give it a show.

Mui

After a good amount digging, I discovered that Next supports transforming imports via SWC, which would allow Webpack to properly tree shake MUI.

However, we are currently using Next v12.1 and import transform was added afterwards see here. This would require us to update to v12.2.6, which does NOT include breaking changes for us.

Upgrading to v12.2.6 and taking advantage of import modularization allows us to go from compiling 11k to 1k modules, which is noticeably faster in the development environment and marginally faster in production.

With v12.2.6 import modularization:

Without import modularization:

Firebase

Firebase is an absolute tank (113KB + unknown size when used in Redux) and is loaded on every single page. Unfortunately, we are using v8.4.1, while tree shaking in only supported v9+ see here.

[ZzRanger]

Nice work! 2020-courses.json was meant to be a temporary solution until the API goes live so we're planning on removing it anyway once we integrate Nebula API.

Regarding MUI & Firebase, I'm cool with upgrading Next & Firebase sometime after beta launch.

[sarthak22gaur]

There are a lot of perf improvements that can be done in this.

1. We can get away with almost 90% of the redux store by using SSR and caching query data.
2. The courses list can be cached as well quite easily
3. Defining better suspense boundaries will greatly increase the UI/UX experience in terms of loading times.