Big bundles

[ebeloded]

The combined weight of vendor and yoroi scripts are more than 21MB, which is enormous for a web application.

This result of this is very long load time and huge memory use. Also, AdaLite is delivering almost the same functionality with only ~400KB, so the problem is not intrinsic to being a Cardano wallet.

@SebastienGllmt mentioned that some meaningful reduction in size would come after transitioning to Webpack 4 (#362). Webpack 4 will definitely shake some trees and eliminate dead code. However, it seems that the big problem is with something else.

Running the package.json through bundlephobila showed that, even though we have some heavy dependencies, such as pdfjs, the combined weight of them all is under 3MB.

Opening the yoroi.bundle.js will show that it contains a lot of stuff that shouldn't be there, such as the information about where on @nicarq machine the project is stored 😱

TODO:

• [ ] Figure out what bloats the bundles and how did it happen
• [ ] Extract translations from the bundle and load only the required locale
• [ ] Split the code. Load heavy non-essential dependencies (such as pdfjs, trezor, ledger, etc) only when required
• [ ] Integrate Webpack Bundle Analyzer to see what else bloats our bundles and remove what we can

Additionally, I suggest adding a size check in CI. This is to ensure that when the process of deployment is automated, we can reliably fail if the bundle size spikes unexpectedly. @rcmorano let me know what you would need for that.

Yoroi deals with sensitive information and I think that every kilobyte of the app should be accounted for, and every dependency reconsidered.

[SebastienGllmt]

This is a duplicate of #362 and a duplicate of the plugin system task

[ebeloded]

Hey @SebastienGllmt, can we close the issues when the problems are resolved in production?

Also, this, and the #385 issues contain suggestions which are worthy to at least discuss.

[rcmorano]

Hey, I can add a size-check-script step in our CI to check for the whole bundle size and/or for individual files. Something like...:

MAX_BUNDLE_SIZE=10240 # kb
MAX_VENDOR_SIZE=1024 # kb
BUNDLE_SIZE=$(du -xs /src/build/ | awk '{print $1}')
VENDOR_SIZE=$(du /src/build/js/vendor.js | awk '{print $1}')
test ! $BUNDLE_SIZE -gt $MAX_BUNDLE_SIZE || echo "ERR" && exit 1
test ! $VENDOR_SIZE -gt $MAX_VENDOR_SIZE || echo "ERR" && exit 1

Although, I don't know if there is a js library that does this in a more standard/elegant/integrated way.

[SebastienGllmt]

Not sure if a check for individual files will be so useful because Mozilla has a strict per-file file size limit which we will use Webpack to enforce.

I'm not sure if a whole-application limit would be useful since we would have to just bump it up whenever we run against it. I can imagine a warning if your PR causes a sharp increase in app size to be useful in preventing a disaster in the future but maybe not a priority right now.

[SebastienGllmt]

I am closing this again.

Figure out what bloats the bundles and how did it happen & Integrate Webpack Bundle Analyzer to see what else bloats our bundles and remove what we can This is covered by #362 which is tracked in Clubhouse so this is a duplicate issue

Extract translations from the bundle and load only the required locale This would only save a few kilobytes so probably not worth the engineering time (at least until we add a lot more language)

Split the code. Load heavy non-essential dependencies (such as pdfjs, trezor, ledger, etc) only when required Having a plugin system is a non-trivial task and should go through the triage process and roadmap planning and not a Github issue