Budibase poor performance and latency issues due to js bundle size

[rauanmayemir]

On the latest v2.9.30 budibase performance is very poor at least for the following reasons:

1. index.js asset bundle is too big, it is 1.7Mb when gzipped and it takes almost 3 seconds for browser to download it (and then unzip it)
2. index.js is a blocking request, meaning the budibase webpage will not render until it gets the bundle. that means each refresh will take at least 3 seconds to load.
3. index.js contains SVGs inside the bundle, I don't think it's reasonable to do that. they should be loaded separately as static assets in a non-blocking way

I would also suggest looking into chunking/splitting the js assets.

All of this leads to a very poor performance and hence bad user experience.

[aptkingston]

Hey @rauanmayemir. This didn't change as of v2.9.30 as far as I'm aware - we've always had a huge JS bundle. I'm aware it's less than ideal, but right now we can't do any sort of code splitting because we allow apps to be versioned independently of the installed Budibase version, which means we store this large bundle inside our object store (minio / S3) for every app. We need a predictable naming scheme in order to be able to discover and serve those files consistently.

I'd love to code split our bundle and do something about this, which is one of the reasons I'm trying to push towards removing our independent app versioning, since it would let me address this.

We also just have too many dependencies in general and the bundle is very bloated (and I apologise for that) but I doubt we're going to prioritise that in the short term. Believe it or not, it used to be much bigger! But there is still a long way to go.

I'm going to remove the bug label here since this isn't a bug, but I'll leave the issue open to raise awareness and hopefully help us prioritise doing something about this.

[rauanmayemir]

Understood, thanks for clear communication. Is it possible to at least try to unbundle SVGs and see if they're actually taking up significant part of the bundle size? (my unsubstantiated estimate is that it's at least 30%)

[aptkingston]

Not a bad guess! I actually built in some profiling last time we looked at bundling - so I can tell you that SVGs take up just under 10% in fact.

A lot of the main offenders are things that serve a very specific purpose and could easily be split out - like our map library for the map component, or QR code scanner, which together are almost 2MB of bundled JS for 2 components which are very rarely used 🙄

[rauanmayemir]

We also just have too many dependencies in general and the bundle is very bloated

This actually leads to a compliance headache. Here's an example of CVEs for apps image:

I'm surprised there's protobufjs, since BB doesn't use protobuf.

I'm guessing lodash is a transitive dependency and a full one at that (instead of using say lodash/core, etc). Maps and charts are the biggest bloaters. I feel like there are some good low-hanging fruits that could help with the bloat, like splitting maps into a separate vendored script and loading it with async so it doesn't block the page render.