Optimizing ScholarX demo application runtime (Bundle.js Analysis)

Hi all :hugs:
Many of you might already know we have an up and running demo scholarX application deployed on https://sef-scholarx.herokuapp.com/. But the existing version had a loading time issue. When we looked into the issue, we figured out that this causes the heavy file size of the bundle.js

This thread is regarding the optimization of the bundle.js file and I’ll be updating my progress here. Feel free to add your thoughts :yum:

2 Likes

I found a Webpack plugin called Webpack-bundle-analyzer which helps us to analyze the bundle.js file. I used this plugin and visualized the bundle.js file of the ScholarX application. First, it was running on Webpack development mode, Therefore the bundle.js was 10.8MB which caused the application loading time very high.

Phase 1:


You may notice, neither of the packages wasn’t concatenated during the development mode. Which consumed a lot of space.

Phase 2:
But later with the ScholarX-frontend-release v1.2.1, We used the Webpack production mode, which reduced the file size to 2.3MB


In this phase plugins such as moment.js consumed so much space, Even though we use them to fulfill a very basic requirement.

Phase 3:
In order to concatenate the plugins further, I found two plugins called Webpack-ModuleConcatenationPlugin and Webpack-ContextReplacementPlugin. After using these plugins I was able to reduce the file size to 1.8MB


I was able to compress most of the files using these two plugins.

Here’s the PR after doing the above changes to the Webpack configuration file.

Update this thread if you have any more ideas/methods to help optimize the application. :yum:

3 Likes

Woah this is very impressive
Good job @Gimhan_minion

1 Like

Interesting task very impressively performed :heart_eyes: .Well done @Gimhan_minion
Anyways didn’t we discussed to remove the moment.js plugin and used builtin Javascript methods for date/time calculations?
Also what is the use of sock-client.js library? Are we using this for server communications instead of axios?

Sure @YohanAvishke that’s an awesome idea. But aren’t we gonna use moment.js even in future requirements? If not we can definitely use the javascript built-in method. And I’m not sure why we use the sock-client.js. @anjisvj Do you have any thoughts on this?

I also have no idea about that sock thing.

We might use moment.js in the future. But we can add it when the requirement comes. Since there is no reason to use it at the moment, let’s remove it and replace the code from builtin functions.

Sure then! will do that :hugs: @YohanAvishke

1 Like