Skip to content
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

Closed
cmdcolin opened this issue Oct 30, 2020 · 11 comments
Closed

Bundle size analysis #1356

cmdcolin opened this issue Oct 30, 2020 · 11 comments
Labels
housekeeping needs to be tidied up, is a drag on team performance

Comments

@cmdcolin
Copy link
Collaborator

cmdcolin commented Oct 30, 2020

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

@cmdcolin cmdcolin added the housekeeping needs to be tidied up, is a drag on team performance label Oct 30, 2020
@rbuels

This comment has been minimized.

@cmdcolin

This comment has been minimized.

@cmdcolin

This comment has been minimized.

@cmdcolin
Copy link
Collaborator Author

cmdcolin commented Feb 9, 2021

Current source-map-explorer with https://github.com/cmdcolin/jb2_lgv_benchmarking_demo (embedded demo)

Screenshot from 2021-02-09 11-34-49

@cmdcolin
Copy link
Collaborator Author

cmdcolin commented Feb 9, 2021

as far as fat to trim

  • NewSessionCards (334kb) probably due to statically bundled pictures
  • react-color (maybe, 69kb)
  • core-js pure, probably duplicate/unneeded polyfills (56.76kb) also maybe overlapping with plain core-js
  • could try to make trimmed down re-exports for embedded?
  • cross-fetch, might be unneeded and included by one of our data adapters
  • @material-ui/data-grid...this was a fun feature to bring in but does bump up bundle size...if it could be lazily included that would be ideal (142kb)
  • rxjs all operators are included (bottom right, 159kb)

@cmdcolin
Copy link
Collaborator Author

cmdcolin commented Feb 9, 2021

browserify-zlib and pako also included, could lobby hic-straw to use pako directly instead of browserify-zlib (i think that is the source)

@cmdcolin
Copy link
Collaborator Author

cmdcolin commented Feb 9, 2021

There is also the idea of doing more lazy includes so that more bundle splitting can happen but unsure what is needed for that

@cmdcolin
Copy link
Collaborator Author

note that the jb2_lgv_benchmarking_demo embedded mode is likely 3mb bundle size total and ~1.1M gzipped

File sizes after gzip:

  1.01 MB  build/static/js/2.07da8a66.chunk.js
  1.59 KB  build/static/js/3.1542c050.chunk.js
  1.21 KB  build/static/js/main.c88980f5.chunk.js
  1.16 KB  build/static/js/runtime-main.2f9fe588.js
  531 B    build/static/css/main.8c8b27cf.chunk.css


@cmdcolin
Copy link
Collaborator Author

cmdcolin commented Feb 10, 2021

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

@cmdcolin
Copy link
Collaborator Author

xref #1905 #1888 for some initial attempts at reducing bundle size

not a bad first pass, about 36% bundle size shaved off, and some lessons learned so that we don't have a continuously increasing bundle size as app logic grows

@cmdcolin
Copy link
Collaborator Author

maybe close for now :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
housekeeping needs to be tidied up, is a drag on team performance
Projects
None yet
Development

No branches or pull requests

2 participants