Web bundle size too big spike

woodenfurniture commented 1 month ago

Overview

Our app bundle size is right on the cloudflare limit. We should investigate way to reduce it before it's too big to deploy.

References and additional details

.

Acceptance Criteria

Options to reduce bundle size.

Need By Date

No response

Screenshots/Mockups

No response

Estimated effort

No response

0xean commented 1 month ago

do we need to serve asset data externally to app
what other solutions exist?

0xApotheosis commented 1 month ago

Initial bundle size for reference

Parsed: 45.9 MB

Gziped: 12.96 MB

gomesalexandre commented 1 month ago

Initial bundle size for reference

Parsed: 45.9 MB

Gziped: 12.96 MB

@0xApotheosis would minifying the base (non-gzipped) generatedAssetData.json save a lot here or wouldn't it be significant?

0xApotheosis commented 1 month ago

Opportunities (2 promising ones that are Pareto-optimized)

Lazy load @ledgerhq:

38% of the the total Gzipped bundle size is from a single part of a single package: @ledgerhq/cryptoassets/lib-es/data/evm.

Minifying generatedAssetData.json

A quick sanity check on this approach (thanks @gomesalexandre) showed that we'd reduce this file size somewhere in the order of 15% (10.8mb down to 9.4mb on a quick test).

Other good candidates for minification are relatedAssetIndex.json (1.46mb) and color-map.json (872kb).

However, the alternative and likely better solution is probably to remove these files from the build entirely by...

Using GitHack to externalize generated files from the build

We could keep these generated files in the existing repo (web), but exclude them from the build and serve them via GitHack.

This alone would reduce the gzipped bundle size by 85%, and the parsed size by 25%.

0xApotheosis commented 1 month ago

Closing this spike as tickets have been spawned which, once completed, should alleviate the issue.

shapeshift / web