-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bundle size analysis #1356
Comments
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Current source-map-explorer with https://github.com/cmdcolin/jb2_lgv_benchmarking_demo (embedded demo) |
as far as fat to trim
|
browserify-zlib and pako also included, could lobby hic-straw to use pako directly instead of browserify-zlib (i think that is the source) |
There is also the idea of doing more lazy includes so that more bundle splitting can happen but unsure what is needed for that |
note that the jb2_lgv_benchmarking_demo embedded mode is likely 3mb bundle size total and ~1.1M gzipped
|
for some perspective the nextstrain fetches a big 2.1mb gzip file, which unpacks to over 57mb json obj in memory from getDataset?prefix=%2Fncov%2Fglobal, but their js bundle sizes is ~469kb (over the wire, presumably gzipped, from filtering on .js in the network tab) looking at https://nextstrain.org/ncov/global |
maybe close for now :) |
We currently download ~3MB multiple times (main thread + webworkers)
This has been the case for awhile and it's hard to trim a lot of fat off
It might be good to do a once-over at some point
<outdated screenshot with crypto removed>
Image generated by running
source-map-explorer *.js
In the build/static/js
For analyzing webworker bundle it is just running that in build/ folder
The text was updated successfully, but these errors were encountered: