所以我们都听说过将 javascript 和 css 捆绑到尽可能少的文件中是件好事。当然是这样，但在我看来，这个故事太简单了。
看看我的逻辑在这里是否有意义。
显然，更少的 HTTP 请求意味着更少的往返，因此更好。但是 - 我对裸 http 知之甚少 - 不是以块的形式发送 http 响应吗？如果一个文件大于其中一个块，它是否必须作为多个（可能是同步的？）往返下载？与此相反，由于现代 Web 浏览器并行下载诸如 javascripts 之类的资源，因此对分块大小以下文件的多个请求会更快到达。
即使分块不是问题，似乎也会有一些最大推荐大小，只是由于丢包的可能性，因为捆绑文件必须等到它完全下载才能执行，而不是脚本必须执行的更宽松的本机规则为了。
显然，还需要考虑浏览器缓存和代码波动的问题，但有人可以证实这一点或解释我为什么不在基地吗？有人有任何数字可以输入吗？
我找不到数字的参考，但我过去从可靠来源读到有人（我认为是 Google 或 FB）对围绕请求并发的效率问题进行了大量研究，当时他们是构建他们的 CDN，并发现在考虑丢包、传输层开销和其他此类因素时，2-3 个并发传输是最佳的。这适用于与单个服务器通信的单个客户端，并且可以通过从多个服务器分发内容来获得少量但显着的效率提升 - 使用分布式 CDN 的另一个优势。
从底部向上 - HTTP，在 TCP 上运行不可避免地涉及许多低级别的往返，因为在发送下一个 TCP PSH 之前必须确认每个 TCP PSH。鉴于以太网 MTU 为 1500（考虑到大量 DSL 和其他基于 ATM 的连接性，实际上通常为 1492），将 TCP 最大有效负载大小设置得更大是没有意义的，因为这实际上会降低效率。由于网页使用的许多（如果不是全部）资源大于~1.4KB，它们将不可避免地在传输层被“分块”（碎片化），而愚蠢的 TCP 有效负载大小设置将导致网络碎片化层也是如此。如上所述，这些传输片段中的每一个都必须在发送下一个之前由接收者确认，从而导致至少几次往返。
在应用层，HTTP 本身也支持“分块”，这与传输层分片问题略有不同。分块传输编码的设计考虑了持久性的概念，并且还为服务器和客户端提供了内存消耗优势。虽然它会使响应稍大一些，但不太可能导致明显更多的往返行程（如果正确实施），并且任何额外的往返行程只是 TCP PSH/ACK 对，而不是全新的 HTTP 请求。分块传输编码的想法是将主体溢出到同一流中的块中，而不是拆分为将在多个流上交换的块。当然，您问题的措辞表明所有HTTP 消息以块的形式传输，而事实并非如此。如果您的服务器配置合理，则只有动态内容和动态压缩的内容会被分块，即使那样也不是所有内容都会被分块。大多数 HTTP 服务器会尽最大努力将响应放入尽可能少的 TCP 数据包中。
至于最大推荐尺寸，我无法给出权威答案，但我会就此事发表我的看法。鉴于在上述参数范围内可能发生的已经无限的变化，最有效的方法在很大程度上取决于您提供的服务以及服务方式。
如果您正在提供一堆静态内容，那么个人传输可能越大整体越好，但需要注意的是：假设我们正在提供一个包含大量客户端动态内容（即 JS 驱动的内容）的网页，我们想要页面以尽快加载。但我们首先需要发送的是呈现显示初始状态所需的内容 - 基础 HTML 显然是我们需要发送的第一件事，但这几乎是给定的。接下来，我们将需要为页面提供初始布局的样式表，以及所需的任何图像——所以一切看起来好像它已经加载了。接下来，我们需要将所有基本客户端代码附加到页面的 Javascript - 这实际上可能相当小。只有当所有这些都被加载后，我们才需要获取更大的资源主体，所以不要将所有对它的引用放在 HTML 头中，在那里您几乎无法控制资源的加载顺序（注意：加载未执行），从您的基本 Javascript 文件动态加载它们。这使您可以创建一个看起来好像已尽快加载的页面，但实际上是在加载不太常用的资源或仅在稍后的几次用户操作后才需要的资源。
如果您动态地提供所有内容 - 通过 PHP/Perl/ASP/Insert Server Side Language Here 传递所有内容 - 那么您还需要考虑服务器端执行时间，但同样的原则也适用。生成标记/样式/脚本/图像/使页面看起来好像已尽可能快地加载所需的任何内容，并且任何需要很长时间才能生成的内容可以稍后通过 JS 加载。
回顾一下，我不确定这对你有多大用处，或者它是否能回答你的问题，但希望它能带来一些有趣的（？）阅读。