Shrink size of main.js to allow for a smaller initial download (and quicker initial page draw)

[tdonohue]

Describe the bug
This ticket is based on discussions occurring in recent DevMtgs and in https://wiki.lyrasis.org/display/DSPACE/DSpace+7+UI+Optimization+Analysis

Based on current analysis, the size of our main.js package is much larger than it should be (currently at 877KB gzipped, but it really should be cut in half or even smaller). A larger main.js slows down the initial page load, and affects the performance of the site.

The size of main.js can most easily be visualized via webpack-bundle-analyzer as described at https://wiki.lyrasis.org/display/DSPACE/DSpace+7+UI+Optimization+Analysis#DSpace7UIOptimizationAnalysis-webpack-bundle-analyzer

Shrinking Notes / Options

1. Some libraries/dependencies are quite large and currently take up a lot of space in main.js. We should filter out any libraries we do not need, look to replace very large ones with alternative smaller ones, and/or lazy-load any that do not need to be a part of main.js.
   • A few PRs already exist to clean up a few dependencies, see Replace Moment.js with date-fns #1903 and Shrink size of Klaro & ban wildcard imports. #1908
2. Related to that, we are not always lazy-loading or delaying download of larger features, resulting in larger initial download before the page is drawn.
   • For instance, it'd be ideal to lazy load Klaro (which is a large library) after the initial page draw. (It's recommended by Klaro to use deferred loading)
3. The "Shared" module (/src/app/shared) is massive (151KB gzipped) and is all included in main.js. It likely needs to be broken up into many smaller "shared" modules which can be lazy loaded where needed.
   • This may be a larger task, but if we could create a basic example of a better approach then others could help out.
   • A basic example of a better approach would also help us avoid increasing the size of the "shared" module in new/upcoming features.
4. IDEALLY, main.js would be shrunk to only include code & dependencies needed on all pages (e.g. header/footer, core modules, core dependencies, etc).
   • All other modules should be lazy-loaded on the pages where they are used.

Expected Implementation

Ideally, this ticket will not be fixed in a single, large PR. We'd instead highly recommend starting with a few example PRs, as those will help reviewers & developers to see correct examples of proper lazy-loading, etc.

That way, as others are building new features & as reviewers are reviewing code, they can avoid increasing the size of main.js

Once Main.js is shrunk, we should look at implementing a strict budget which automatically checks (via GitHub CI) when PRs increase the size of Main.js significantly. This might be achieved via Google Lighthouse or similar. While this is not required to close this ticket, we should discuss options on how best to automate checks of main.js for the future.

[tdonohue]

@artlowel : Here's the ticket for shrinking the size of main.js -- I've assigned to you for 7.5. I've copied my notes from today's meeting into here. We can use this ticket for more discussion/analysis.

Just stressing again that I highly recommend we fix this through a series of smaller PRs, as I think that approach will help all our development team to learn better ways of keeping main.js small & doing more lazy loading.

[tdonohue]

NOTE: As part of this work, we may want to also shrink the size of the homepage background image in the "dspace" theme. It's one of the slowest objects to load because of its size.