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

Production bundle size #43

Open
qualitymanifest opened this issue Feb 1, 2020 · 1 comment
Open

Production bundle size #43

qualitymanifest opened this issue Feb 1, 2020 · 1 comment

Comments

@qualitymanifest
Copy link
Contributor

qualitymanifest commented Feb 1, 2020

node_modules in the production bundle is nearly 7mb. It looks like something is going wrong during the build step and the prod bundle is getting dev packages. Once that is taken care of there is room for some tree-shaking and other optimization (like lazy loading LocationTable since material-table is pretty big)

Steps to reproduce

npm run build
npm run analyze
@qualitymanifest
Copy link
Contributor Author

qualitymanifest commented Feb 2, 2020

Looks like the problems with react-dom and lodash are actually just related to issues with the analyze script. Applying this change fixes that issue.

With those fixed, node_modules is still at 5.7mb, with material-ui and material-table tied as the top contributors with 1.2mb each.


As for the minified & gzipped size, when starting with a clear cache and using the chrome devtools iphone 5s simulator, you get 2.56mb transferred. (For consistency when tracking this, device screen size makes a pretty big difference due to the amount of map that needs to be loaded)

1.1mb of that 2.56mb is the data coming from the API. This is probably where the biggest difference could be made, by only projecting fields necessary for the map (latitude, longitude, name, type, id), since the vast majority are unused and get fetched anyway when you visit a page that needs them. Additionally this would speed up the geoJSON conversion since there wouldn't be a need to destructure each object.

Lazy loading LocationTable removes .16mb. After that, the next most significant thing would be material-ui. The transferred size of that is .12mb, which indicates that code splitting isn't working properly

With all of these changes, I'm guessing that initial load could be brought down to under 1.5mb transferred including the API and map data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant