Http 由于分块或数据包丢失，捆绑/组合js文件是否有最大建议大小？

所以我们都听说，最好将javascript和css捆绑到尽可能少的文件中。当然是这样，但在我看来，这个故事太简单了

看看我的逻辑在这里是否合理

显然，更少的HTTP请求意味着更少的往返，因此更好。然而——我对裸http不太了解——http响应不是成批发送的吗？如果一个文件大于这些块中的一个，它不需要作为多个（可能是同步的？）往返下载吗？与此相反，由于现代web浏览器并行下载javascripts等资源，因此对小于分块大小的文件的多个请求将更快到达

即使分块不是一个问题，似乎也会有一些建议的最大大小，这仅仅是因为数据包丢失的可能性很高，因为捆绑文件必须等到完全下载后才能执行，而脚本必须按顺序执行的本机规则更为宽松

---

显然，还有浏览器缓存和代码波动的问题要考虑，但是有人能证实这一点，或者解释我为什么偏离了基础吗？有人有任何数字可以说明吗？

我找不到数字的参考，但我过去从可靠的来源读到，有人（我认为谷歌或FB）在构建CDN时，对围绕请求并发的效率问题做了大量研究，并发现在考虑数据包丢失、传输层开销和其他因素时，2-3个并发传输是最优的。这适用于与单个服务器通信的单个客户机，通过从多个服务器分发内容，可以获得较小但显著的效率提高—这是使用分布式CDN的另一个优势

从底部向上-HTTP，在TCP上运行不可避免地涉及许多低级别的往返，因为每个TCP PSH必须在发送下一个之前进行确认。鉴于以太网MTU为1500（鉴于DSL和其他基于ATM的连接的丰富性，实际上通常为1492），将TCP最大有效负载大小设置得更大是没有意义的，因为这实际上会降低效率。由于网页使用的许多（如果不是全部）资源都大于~1.4KB，它们将不可避免地在传输层被“分块”（碎片化），愚蠢的TCP有效负载大小设置也将导致网络层的碎片化。如上所述，在发送下一个传输片段之前，接收者必须对每个传输片段进行确认，这至少会导致一些往返

在应用层，HTTP本身也支持“分块”，这与传输层碎片问题略有不同。在设计时考虑到了持久性的概念，并且还为服务器和客户端提供了内存消耗方面的好处。虽然它会使响应稍微大一点，但不太可能导致更多的往返（如果正确实现的话），任何额外的往返都只是TCP PSH/ACK对，而不是一个全新的HTTP请求。分块传输编码的思想是将主体分为同一流中的块，而不是分为将在多个流中交换的块。当然，您问题的措辞表明所有HTTP消息都是分块传输的，但事实并非如此。如果您的服务器配置合理，则只有动态内容和动态压缩的内容才会被分块，即使如此，也不会所有内容都被分块。大多数HTTP服务器将尽最大努力将响应放入尽可能少的TCP数据包中

至于建议的最大尺寸，我无法给出权威性的答案，但我会给出我对此事的看法。考虑到在上述参数范围内可能出现的无限变化，最有效的方法在很大程度上取决于您所服务的内容和服务方式

如果您提供的是一堆静态内容，可能单个传输的内容越大，整体效果越好，但需要注意的是：假设我们提供的网页包含大量客户端动态内容（即JS支持的内容），我们希望页面尽快加载。但我们首先需要发送的是呈现显示初始状态所需的内容——基本HTML显然是我们需要发送的第一件事情，但基本上是这样的。接下来，我们需要一个样式表，该样式表给出了页面的初始布局，以及所需的任何图像，这样所有内容看起来都好像已经加载了一样。接下来，我们需要将所有基本客户端代码附加到页面的Javascript—这种可能性实际上相当小。只有当所有这些都已加载时，我们才需要获得更大的资源体，因此，不要将对这些资源的所有引用都放在HTML头中，在HTML头中，您几乎无法控制加载资源的顺序（注意：loaded not executed），而是从基本Javascript文件中动态加载它们。这允许您创建一个页面，该页面看起来好像已尽可能快地加载，但实际上正在加载不太常用的资源或仅在以后的几个用户操作后才需要的资源

如果您是动态地为所有内容提供服务的——在这里通过PHP/Perl/ASP/Insert服务器端语言传递所有内容——那么您也需要考虑服务器端执行时间，但同样的原则也适用。生成标记/样式/脚本/图像/使页面看起来尽可能快所需的任何内容，并且需要很长时间才能生成的任何内容都可以稍后通过JS加载

回顾这篇文章，我不确定这对你有多大帮助，也不确定它是否能回答你的问题，但希望它能让你受益匪浅