javascript - 什么时候 JavaScript 小到值得内联(以获得最佳性能)？

Question

假设我正在为客户构建一个 10 页的静态网站，整个网站只有几行 JavaScript(不到 1KB)。在这种情况下，我猜想最好(为了性能)将 <1KB 的 JavaScript 代码 inline 放在每个页面的脚本标记之间，而不是放在外部 .js 文件。额外的带宽消耗(在页面之间移动时)对于删除整个 HTTP 请求来说可能是值得的。

另一方面，如果我在同一个网站上有 200KB 的 JavaScript，那么我肯定会把它放在一个单独的文件中，以减少在网站页面之间移动时的带宽。

但我不知道“截止点”应该在哪里。如果我有 5KB 的 JS，我应该把它内联到我的 HTML 中吗？ 10KB呢？ 20KB？

显然，“分界点”要视情况而定，例如移动网站可能有所不同。但是，如果有人有任何有助于指导这一决定的一般性建议，那么我想听听他们的意见。

(注意:我只对这里的性能感兴趣，而不是可维护性等。我可以将我的代码保存在单独的文件中，但使用某种构建过程或服务器端自动内联它的中间件，因此可维护性不会成为问题。)

(加分点:请让我知道内联 CSS 与外部 CSS 的所有注意事项是否完全相同。)

Answer 1

我在这里严格地谈论性能，更像是一个思想实验(请原谅缺乏实验严谨性)。

如果您正在内联 javascript，是的，您确实可以节省时间，因为所有事情都在一个 http 请求中完成。但是，您应该考虑服务器动态生成您需要的网页所需的时间(SSL 也会为此增加时间)。

最佳情况

如果您可以创建一个生成缩小的 javascript 并将其注入(inject) html 页面的构建，并结合 gzip 压缩，您应该会得到更低的带宽。压缩的文本越多，与每个请求单独 gzip 相比，您的 yield 就越大。最终，这意味着如果您可以让它使用所有内联的 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-u-s-broadband-connection-speed-is-now-5-3-mbps/)，对于宽带用户，我们平均使用5.3 mbps(即 .6625 MB/s 或 678.4 KB/s 或 .6784 KB/ms)。这意味着对于普通宽带用户，您需要下载大约 100KB 的 gzipped+minified javascript 才能与之相等。

请自行调整参数，看看这对您的观众意味着什么。这个数字，无论您计算它是什么，都是您最好在线提供它(通过服务器生成的响应)而不是从外部获取/缓存它的点。

总而言之，我认为出于性能原因，这根本不是瓶颈。压缩 + 缩小后的 javascript 的大小通常可以忽略不计，而且它必须处于无法维护的数量级，这才是重要的。