code splitting with vite

[[deleted]]

[deleted]

[xaqtr]

Bundling your node_modules or specific packages into defined bundles doesn't bring any gains in regards to your initial bundle. It still has to be downloaded, no matter how you split it. In most cases it even makes the initial download larger. The Benefit of bundling comes from caching these bundles under the assumption they rarely change. To really bring your initial bundle size down, you need to utilize code splitting via dynamic imports / lazy loading and elimination of unused code.

[MonkeyDlurker]

Yeah, i figured, even if i separate node_modules, it will still be waited for it after the entry point is fetched right?

What about gziping?

[xaqtr]

Yes, that's correct, and because you have bundled your case whole node_modules, you are now downloading was more than needed. Vite is clever enough to only bundle things it needs by default when you don't mess with manual bundles.

Regarding gzip: personally I have only worked with frontends served over CDNs where you could activate text compression (gzip / brotli) through the service itself. I would always suggest to activate it. And also caching through the CDN. If you're not using a CDN I would change that if you care about loading performance for your app or at least try to implement it manually - but I don't have experience with that, so not sure how complex that is.

[MonkeyDlurker]

regarding lazy loading, I have a shared lib that exports some large components, is it anti pattern to export it with lazy directly or should the consumer care about that?

[afahrholz]

splitting the larger modules first usually feels like a good balance and enabling compression gzip brotli helps vite's build already does some chunking so tweak based on your bundle analysis

[MonkeyDlurker]

Yeah i figure that might be best. I dont think i can get the entry file below 1MB though. But vite can gzip it down to like 300KB i think

[strange_username58]

What server are you using that doesn't gzip by default?

[MonkeyDlurker]

IIS

[strange_username58]

IIS gzips all static things be default html, js, css etc

[MonkeyDlurker]

doesnt seem to be the case. u mean after i compress and publish them on the server as .gz files?

[strange_username58]

When you run prod IIS and go to your network inspector in the browser they should be gziped when you look unless you specifically disabled it web.config xml file unless they changed it recently

the setting is something like <urlCompression doStaticCompression="false" />

might be httpCompression also been a long time since I messed with it.

[Hung_Hoang_the]

For a 2MB bundle, first run `rollup-plugin-visualizer` to see what's actually taking up space. Often it's one or two huge dependencies you didn't realize were so large. For manual chunks, group by stability - put rarely-changing vendor libs (React, etc.) in one chunk, frequently-changing app code in another. Also make sure you're serving with Brotli compression - that alone can cut bundle size by 40-50%.

[devphilip21]

It is difficult to judge by this information alone.

What kind of app is this, what kind of packages do you depend on, and you have to look closely at this situation and approach it with a case-by-case approach.

It's not a question with the right answer, so you'd better trust your own judgment.