具有多个包的Browserify的效率

时间:2015-01-03 01:17:16

标签: javascript browserify dynamic-script-loading

我是Browserify的新手,我正在努力弄清楚如何让客户需要下载的数量更高效。

我有一个网络应用,它使用许多不同的第三方库和自定义代码。使用Browserify,似乎人们建议的一般方法是将所有内容包装成一个大的bundle.js。由于以下几个原因,这对我来说似乎非常低效:

例如,假设您的bundle.js包含lib1, lib2, lib3, customLib

  1. 如果您的网络应用程序的一部分只需要lib1,则客户端仍然需要下载巨大的bundle.js,并且最终不会使用其中的75%。已下载浪费的字节。不必要地增加了页面加载时间。
  2. 如果您的customLib是您经常迭代的一段代码,那么每次更改时,您的客户都必须重新下载bundle.js,再次下载大量第三方库; t改变了......
  3. 您的网络应用的其他部分可能会使用lib2lib3,但客户可能会或可能不会去那里,他绝对浪费带宽下载整个bundle.js。< / p>

    我已经看到过将您的捆绑包拆分成多个捆绑包的建议。但到底是什么?如果一个页面使用lib1,则另一个页面使用lib1lib2,另一个页面使用lib2lib3,那么如何将其拆分?您将它分成多个捆绑包的次数越多,您是否能够摆脱bundle.js的优势?

    Browserify似乎受到高度重视,所以我希望我在这里错过了一些东西。将许多库和自定义脚本捆绑在一起的正确方法是什么?人们称Browserify为#34;脚本加载器&#34;但是我过去看到的每个脚本加载器(如yepnope等)都使用逻辑来确定要下载的脚本,这似乎是一个更有效的解决方案,而Browserify似乎希望客户端下载一切...

2 个答案:

答案 0 :(得分:7)

不确定答案是否符合SO格式。但不过......

手册的

Partitioning Section描述了以下两种技术

  1. factor-bundle因素将2个或多个入口点放入单个捆绑包中。

  2. partition-bundle与factor-bundle相同,但使用async loadjs函数进行运行时加载。

  3. 因素包

    <script src="/bundle/common.js"></script>
    <script src="/bundle/x.js"></script>
    

    具有异步加载回退的分区包

    loadjs(['./x'], function(x){...});
    

答案 1 :(得分:1)

Substack只是published this gist解释如何拆分包。他建议像这样使用factor-bundle

browserify x.js y.js -p [ factor-bundle -o bundle/x.js -o y.js ] \
  -o bundle/common.js