Closed klinker24 closed 5 years ago
I think this is a great idea. This was on my list to fix as well.
I'll test this shortly.
I don't know if it's worth making this change. The vendor payload is 440kb gzipped and Initial render occurs at 800ms. With the amount of dependencies we have, it may not be worth it to chunk it. If we do chunk, we should combine some of the vendor files so we aren't loading 15-20 with every application.
Wanted your opinion on this @Serubin. My knowledge on webpack is limited, to be honest.
Whenever we do a production build, it throws all kinds of warnings that our bundle size is huge. I have dug into this in the past and reduced some of the dependencies (especially firebase), but it is still very large.
Webpack has a plugin to split chunks though. While this will not help the download size or page render time for the first time that the user opens the app, but it should improve the caching and download rates for these js bundles as we deploy changes.
This takes the
build
output from something like this:To something like this:
I am not sure if there are things that I am not thinking about here, or not. This seems to be an improvement for me, with modern caching. This article discusses it a bit more: https://medium.com/hackernoon/the-100-correct-way-to-split-your-chunks-with-webpack-f8a9df5b7758