多年来，Web开发人员一直遵循最小化HTTP连接加速应用程序的逻辑，因为浏览器不会因代码的下载/执行而窒息。例如，雅虎长期以来一直吹捧他们的best practices，并告诉我们将CSS / JavaScript /图像资源合并到单个文件中 - 从而减少HTTP请求的总数并压缩总资源大小。
但其他＆＃34;最佳做法＆＃34;存在关于提高网页速度的问题 - 特别是最大化parallel HTTP downloads（来自Google）的数量。这种方法告诉我们，通过在多个主机名之间传播HTTP连接，浏览器可以同时执行更多操作。
因此，随着现代Web应用程序变得非常庞大（例如仅3MB +的JavaScript），必须提出这样的问题：
我的应用程序在单个文件中使用3MB + JavaScript加载会更快吗？或者，如果多个较小的文件分布在主机名中，它会加载得更快吗？
为了简单起见，我们还应该假设其他＆＃34;最佳实践＆＃34;正在被追随，所以这个问题最好存在于真空中。
我还没有看到关于这个主题的任何经验数据，但我想必须有一个点，这些方法的表现有所不同 - 所以知道甜点存在的位置将是理想的。
答案 0 :(得分：3)
我认为这取决于浏览器可用的套接字数量。假设浏览器有4个插槽可用，4个较小的请求将比1个大请求快。
这里的诀窍是在启动时了解您的应用程序将发送什么请求，并最大化浏览器可以使用的套接字＃的请求数。我相信浏览器只有4个，但说实话，我还没有看到现代浏览器中这个数字是否有所改变。
看起来每个浏览器都有自己的套接字数，有些有2个：Max parallel http connections in a browser?
https://stackoverflow.com/a/985704/925782说IE10是8个插槽的赢家，哇，去IE：）
高速缓存控制也会在这里发挥作用，当然第一次加载就是一切，后续加载会减少实际请求。
如果你想变得怪异：http://www.stevesouders.com/blog/2008/03/20/roundup-on-parallel-connections/
我同意一些图表和真实数据将是一篇很棒的博客文章，我的回答纯属理论性质。
答案 1 :(得分：1)
我会选择并行下载。
较小的JS文件可以比一个怪物大小的包解析得更快。在大多数情况下，您不需要同时使用所有JS。
由于昂贵的http请求，连接资产被视为当前的更好做法。 HTTP / 2.0目标之一是通过在同一tcp连接中复用请求来降低成本。 HTTP / 2.0中的服务器推送可以通过提前向客户端发送一些重要资产来进一步利用它。
Chrome，FF，Opera和IE11已经支持HTTP / 2.0，并且支持流行的网络服务器（apache，nginx）