Imo, eagerly preloading everything is almost always better. In optimal conditions, it eliminates waterfalls and load times completely for silky smooth native-like experience. In poor reception areas (bus/car/subway) if you lazy load , the user may not have connectivity when they trigger a load and causes your app to stop working. This won’t happen if you eagerly load.
(From my own view as a user) I would much rather load everything while i have connectivity than load a little faster but not be able to use my phone when i get on a train.
That isnt to say splitting is bad, its actually dynamic imports that cause the problem, which is just the common mechanism most people use to tell the bundler how to split chunks. Although, i think it is ineffective and actually causes bad user experience.
Historically, http 1 and chrome used to only allow 5 simultaneous request in-flight at a time. It’s now 50. From my own “play testing” the ideal strategy seems to be to synchronously load everything into namespaces manually chunked where necessary. Kind of like a vendor chunk, but just a little smarter with smaller groups. Also in chrome, specifically 30kb - 50kb sized files are given some fast path, so that is the size to aim for. Given all this, it seems to be an argument for chunking babylon up right? But in practice, I still find it much much better to just namespace import everything up front. Sidenote: es module imports are a post-bundle construct meant for the browser. Import statements are meaningless pre-bundled. Webpack v3 and below , and to some extent still, just had problems tree shaking es modules, because in webpack “modules” are files, whereas in rollup, it actually parses the AST and does codegen. Rollup will extract a single function out of a massive file if configured correctly and the bundle doesnt have side-effecty imports, which sadly, babylon does 
. There is a balance between fixing treeshaking and breaking changes though, and I absolutely love and adore that babylon doesnt break things. I’ve thought about it for a while actually, and i think the best fix would be to move to a module structure under babylonjs that is similar to lodash. Nothing would have to break as it is, where you import from babylonjs and you get everything , or you can import from babylon/x and get x, just like you can import from lodash/merge and only get merge. There are existing babel plugins to give cjs bundlers like webpack some help too (although it actually isnt needed in most cases). The nested imports could just re-export from @babylon/namespaces , which should be considered private apis, and do the same for the babylon-x modules, while deprecating (but maintaing) them in favor of just babylon/x. What are your thoughts on that?