It’s this time of the year that I need help with minimalizing bundle size. (I opened a post before and I was mentioning this, so here it is).
I finish the app and I cant reduce the bundle size below 240kB. Google Lighthouse is telling me that I should be able to reduce the size to 140kB.
I started investigating. I’m using RollupJS for bundling into module.
And after I added the Rollup analyzer I noticed that: I got stuff that I will never use:
Bones/bone.js
Particles (BTW it imports StandardMaterial so if you want to use only NodesMaterials instead if you use it you will bundle StandatdMaterial for no reason)
Lights/light.js
Behaviors/Cameras
and some more that I can’t get rid of but I do not use. They just over-blow my bundle. Tree shaking is not getting rid of them as well.
I use version 4.2 and a lot of times I saw opinions that someone said to build a version 4.2.1 with some improvements. (I was one of them as well for the fix that is in version 5 but not 4 for passive event listeners).
So how can this be fixed? Cause when I did a test build with version 5 my bundle size went from 240lkB to 290kB and Lighthouse is not liking this at all.
The problem is that I got packages that I do not use at all and they are like 10% of my bundle still.
There 240kB it’s still too much even for my clients to accept.
I need a way of cutting that out. With modules that should be tree shaken but it’s not. So that is the problem. I found an article that the empty scene should be 120kB. So there is still a lot to remove. But it’s just imported in other packages for no reason.
So Light when you do not have light in the scene and no shadows.
StandardMaterial when you add SolidParticle system when you got all materials NodeMaterials.
Camera Behaviours when you do not use them at all.
Bones when you do not have any meshes with them.
Those are the issues.
There are a lot more small things. and there are dozens of them.
@sebavan Any suggestions? Or can you make a 4.2.1 build that will sort some of the things that are now fixed in version 5 also for your stable version?
I am not sure who provided the 120kB figure. I have to honestly say I don’t know the right number by heart
I am also not sure what exactly is wrong with a bundle bigger than 240kB. But there are clients, and they have requirements, which I can understand.
Babylon has historically used side-effects in our modules. This is why proper tree shaking is not working as you would expect 100% of the time. It also has the scene as the center of your project, which is a class importing many of the framework’s modules. The bundle size is something we are working hard on improving, and I do hope to provide some good news for 5.0, but we can’t promise anything, as there are many other fields to tackle.
If you find something odd (like the imports you are referring to there), it would be great to get that reproduced somehow (maybe even sharing a repository showing the issue), and we will do our best to take care of that as soon as we can.
Yep. The inspector is bundled (hence - can not support tree-shaking). We see the inspector as a debugging tool and less for production (though it is, of course, usable in production), so we don’t put our efforts regarding bundle size when it comes to this package. Same thing I wrote about 5.0 is valid here - we hope to change the structure to support tree shaking for all bundles.
@slin Google Lighthouse score that is marking Big bundle size and adds Blocking time on load.
@RaananW@inteja 240kB it’s after gzip So not so great. And I got no inspector and so on. Just the imports to the last possible import depth path. In version 5 the bundle goes up by 50kB so even worse. But those imports like Bones are there for no reason. How to reproduce this just make a simple scene build with es6 BabylonJS repo and analyse it like the article below shows.
rollup-plugin-visualizer - to have a graph like in this article
and
rollup-plugin-analyzer - to see the dependency that might not be needed. (MeshBuilder change to a specific builder like PlaneBuilder makes a difference)
I’m really disapointed. In the new project I do not have eny light and I got Light imported anyway. Tools in Misc are bundling so many things that are not important. Would love to get rig of them.
Also fix the passive event listeners in version 4 that was fixed in v5. But version 5 is not stable and it adds bundle size. Im really looking forward for BabylonJS 4.2.1 to fix some obvious things.
Can anyone from Babylon team make a decision about this?
To make a BabylonJS 4.2.1 fix release that will fix some small things like that? Like passive listener and bundling not needed imports. This is what this question is about.
Passive listeners are fixed in v 5 and code base for the PR will be the same in 4.2. You just need to realise it.
And Imports just take the StandardMaterial (remove from SolidParticleSystem) and Bones (core) from imports when somebody do not use it.
I’m interested in reducing bundle size. My build is 240kB on v4.2 and 290kB on v5.
And 5 is not stable yet so I will not use it in production.
And many people asked about this post release. Cause they also waiting for stable and smaller version 5. I asked about version 5 stable and there was no date or even estimate.
And Im happy with performance that we ave now and we will like to improve our early live version cause some clients are mentioning those points.
What we call stable is only for “communication moment” . I can guarantee you that 4.2 is less stable than 5.0. it is already used in production in several microsoft environment (like PPT or Flipgrid or OneDrive)
My recommendation would be to check why 5.0 is bigger in your case. It should NOT be bigger. and we can even help to reduce the dependencies to get you on a smaller version
So If it can be smaller then great but once I updated from 4.2 to 5 alpha 19 my bundle size when from 240kB to 290kB. There are some features that I like and will like to use wright away. But how can I reduce the size?
I’m sorry but this is company code I cant share it with you. I just want to know how to remove those packages when I’m not using them.
And how to minimize Babylon 5 version that is bigger than before. I use proper imports with the longest and most pointing path and I still got things that I do not use.
Light and Bones, camera behaviors, StandardMaterial while using Solid particle system. Those are the main ones that I think you should look at.
I will try to make a repo or some screens when I have time.
I would live to force remove even those Imports. I know I’m fighting for every kB there is. Last check that I did save 0.4kB But those imports are a lot to me.
And please do not tell me why do you do it when this is small and stuff. I know. But I got clients that require this and I need to make this a reality. So please help with removing this instead of telling me that this is so little and so fast and I got a lot bigger and it’s OK. It’s ok for your situation but not mine.
We do understand your pain. We are doing to best we can to provide the best tree shaking, while still staying in line with our base principals. The main principal here is backwards compatibility. We will not remove something just for the sake of modernizing the framework.
As I wrote in different threads (and probably in this one as well?) - I will find the time to improve babylon’s build system and the way we are dealing with imports. Try to reduce or remove completely side effects is a hard task, especially since we initially built babylon with namespaces in mind.
We appreciate any feedback, but you have to understand that this is a 7+ years old framework that we continuously improve.
And trust me when I say that - we are not happy with the situation and we do not think what you are saying is wrong. It just a matter of time and priorities. So much to do in so little time.
So not so great. And I got no inspector and so on. Just the imports to the last possible import depth path. In version 5 the bundle goes up by 50kB so even worse. But those imports like Bones are there for no reason. How to reproduce this just make a simple scene build with es6 BabylonJS repo and analyse it like the article below shows.
But those imports are a lot to me.