how exactly bundle size works
Hi. I think it's very newbie & dumb question. But i've been trying to get my head bundle size .
According to google
An app's bundle size is the amount of JavaScript a user will have to download to load your app.
So does that mean not each & every dependency contributes to bundle size?
e.g. if im using nextjs as full stack and i have mongoose as a dependency what shouldn't contribute to client side Js.
So bundle size of a page is only based on imports we have in that file?
Does that mean each & every page has different bundle size because imports & data varies ?
And what exactly is relation between build size & bundle size ?
Also if the bundle size is based on imports . Should i be worried about build size?3 Replies
Unknown User•2y ago
Message Not Public
Sign In & Join Server To View
This is an area thats gotten murkier and requires a bit of nuance, especially when talking about recent frameworks.
simple spa without code splitting means you have 1 monolithic import. sometimes you might see this in electron apps or other edge cases.
An spa with code splitting, utilized lazy loading to only download resources when needed. this is often done at page boundaries.
this is def an improvement as you decrease initial bundle size, but you might have issues between pages if network connection is lost.
still avoiding full reload of an mpa tho
talking about whole app or page-wise bundles is pretty straight forward. but when you have advanced hydration and reusability, you have bundles that may depend upon user interactions. now you end up considering the bundles at component and closure levels given particular flows of user activity.
(Network Error boundaries may get a little more confusing tho. with spa the whole app or page wont load/work. with these hydration methods, specific interactions may break at any moment.)
these were mostly MPA techniques, but the lines are blurring in the search for a sort of grand unified theory of frontend frameworks and addressing the two app problem/isomorphic design.
overall, bundle size alone doesnt tell the whole story. If you care about optimization, you're looking at many aspects and tradeoffs – bundle sizes, parse times, paint times, time to interactive, imports vs script elements, etc.
Build size doesn't necessarily correlate to what hits the client unless you do things naively (ie not code splitting spa)
You'll sometimes see comparisons between spa frameworks comparing bundle sizes. this is mostly to get a sense of how much overhead the component and/or reactive systems add to apps at various scales
sorry to ramble, but its not a straight forward topic and has led to on going discussions about how to benchmark all this
Thanks a ton for explaining 😃.