假设我正在为客户构建一个 10 页的静态网站，而整个网站只有几行 JavaScript（不到 1KB）。在这种情况下，我猜最好（为了性能）将 <1KB 的 JavaScript 代码内联在每个页面的脚本标记之间，而不是放在外部.js文件中。额外的带宽消耗（在页面之间移动时）对于删除整个 HTTP 请求可能是值得的。
另一方面，如果我在同一个网站上有 200KB 的 JavaScript，那么我肯定会把它放在一个单独的文件中，以减少在网站上的页面之间移动时的带宽。
但我不知道“截止点”应该在哪里。如果我有 5KB 的 JS，我应该把它内联到我的 HTML 中吗？10KB 怎么样？20KB？
显然，“分界点”将取决于具体情况，例如移动站点可能会有所不同。但是，如果有人有任何有助于指导这一决定的一般性建议，那么我想听听他们的意见。
（注意：我只对性能感兴趣，而不是可维护性等。我可以将代码保存在单独的文件中，但使用某种构建过程或服务器端中间件自动内联它，因此可维护性不会成为问题。）
（加分点：如果所有考虑因素与内联 CSS 与外部 CSS 完全相同，请告诉我。）
我在这里严格地谈论性能，更像是一个思想实验（请原谅缺乏实验严谨性）。
如果您要内联 javascript，是的，您确实可以节省时间，因为一切都在一个 http 请求中完成。但是，您应该考虑服务器动态生成所需网页所需的时间（SSL 也会为此增加时间）。
最佳案例
如果您可以创建一个生成缩小的 javascript 并将其注入 html 页面的构建，并结合 gzip 压缩，您应该会导致低得多的带宽。与每个请求单独 gzip 相比，您在压缩中粘贴的文本越多，您的收益就越大。最终，这意味着如果你可以让它静态加载一个包含所有 javascript/css 内联的 html 页面，这意味着它肯定会更快。
正常情况（使用动态 html 和共享 js 库）
一些stackoverflow帖子的小样本以及它们如何影响我自己的带宽：
304ms 9.67KB
204ms 11.28KB
344ms 17.93KB
290ms 17.19KB
210ms 16.79KB
591ms 37.20KB
229ms 30.55KB
从这一点来看，似乎每个 http 连接所产生的开销（不考虑文件大小）约为 150 毫秒 - 也许在最坏的情况下。现在，问题是，文本（在您的情况下为 javascript）必须有多大才能使您的带宽产生 150 毫秒。根据这篇文章 (http://www.telecompetitor.com/akamai-average-us-broadband-connection-speed-is-now-5-3-mbps/)，对于宽带用户，我们平均与5.3 mbps（即 0.6625 MB/s 或 678.4 KB/s 或 .6784 KB/ms）。这意味着对于普通宽带用户，您需要下载大约 100KB 的 gzipped+minified javascript 才能使其相等。
请自行调整参数，看看这对您的观众意味着什么。这个数字，无论你计算它是什么，都是你最好内联（通过服务器生成的响应）提供它而不是在外部获取它/缓存它的点。
总而言之，我认为出于性能原因，这根本不是瓶颈。压缩 + 缩小的 javascript 的大小通常可以忽略不计，而且它必须达到不可维护的数量级才重要。
分界点是 0KB——“什么时候 JavaScript 足够小到值得内联”的答案是“从不”。
除了您说您不想考虑的可维护性问题之外，无论如何它对性能更好。是的，您第一次引用该文件时有一个额外的 HTTP 请求.js，但之后它会被缓存，因此您的整体流量/带宽会随着时间的推移而减少。
CSS 文件也是如此。
使用内联 JS 或 CSS 使页面更重比初始获取文件的额外请求成本更高（除非您在.html整个页面缓存很长时间的情况下提供完全静态的服务）
简短的回答：这取决于！
假设：
做数字。粗略估计额外的 HTML 会产生多少额外的流量，与其余流量成比例，然后决定您是否认为这是一个可以接受的折衷方案。
如果是 1%，则可能不值得担心。但如果是 50%，那么您可以通过将脚本放在单独的文件中来将流量减半。