Building code for production is always an attempt to balance the pros and cons of different solutions. On the one hand, a developer wants his code to be loaded and executed as fast as possible. On the other hand, he does not want to load code that will not be used by the project users.
Besides, developers need to be sure that their code is as good as possible for caching. The big problem with code bandling is that any change to the code, even a single changed line, results in cache invalidation of the entire bandle. If you deploy an application consisting of thousands of small modules (represented exactly as they are in the source code), then you can safely make small changes to the code and still know that most of the application code will be cached. But, as I mentioned earlier, this approach to development can also probably mean that it can take longer to load code the first time you visit a resource than it would with more traditional approaches.
As a result, we face the challenge of finding the right approach to bandwagoning. We need to strike the right balance between the speed of loading materials and their long-term caching.
Most bandlers, by default, apply code splitting techniques with dynamic import commands in mind. But I would say that splitting code only with dynamic import orientation does not allow you to break it into small enough fragments. This is especially true for sites with many returning users (i.e. in situations where caching is important).
I believe that you should break code into as small fragments as possible. You should reduce the size of the fragments until the number of fragments grows so large that it affects the loading speed of the project. While I definitely recommend that everyone do their own analysis of the situation, if you believe the rough calculations in the study I mentioned above, there is no noticeable slowdown in loading speeds for less than 100 modules. A separate study devoted to HTTP/2 performance did not reveal any noticeable slowdown of the project when loading less than 50 files. There, however, they tested only variants where the number of files was 1, 6, 50 and 1000. As a result, 100 files is probably a value that can be used without fear of losing the download speed.
So, what is the best way to split code aggressively, but not too aggressively? In addition to code separation based on dynamic import commands, I would advise you to look at code separation by npm-packages. With this approach, what is imported into the project from the node_modules folder is placed in a separate fragment of the finished code based on the package name.
