3 ms·
If I'm not mistaken this is actually the whole point of Webpack. Instead of serving 8,000 npm modules on each page load it goes through and makes one mega-bundl
by nexuist 7y ago
If I'm not mistaken this is actually the whole point of Webpack. Instead of serving 8,000 npm modules on each page load it goes through and makes one mega-bundle that only includes the code that gets called.
- rijoja 7y agoThat is exactly the purpose of webpack, but that requires that you rebuild your website with webpack. Some sites might be even decades old and a rewrite would be a major undertaking. Also this method would work with code within the modules itself. Webpack works on a module basis, i.e. import statements. My approach would rather look at the code on a line or function basis and exclude unused code within the module itself. Every page is ran through in different browser and what the client actually is executing is measured instead of a higher level dependency graph. One thing that could happen with the webpack approach is that if say the frontpage js bundle and the login js bundle is different the bundles have to be downloaded separately the cache is not really utilized. I do understand that the approach of automagically slicing javascript files like this might be way trickier than it sounds, which is why I propose that this would be a semi-autonomous process to some extent (at least in the beginning).