什么时候 JavaScript 足够小，值得内联(以获得最佳性能）

When is a JavaScript small enough to be worth inlining (for best performance)?

本文关键字：最佳 性能 JavaScript 值得 什么时候      更新时间：2023-09-26

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

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

但我不知道"分界点"应该在哪里。如果我有 5KB 的 JS，我应该把它内联在我的 HTML 中吗？10KB呢？20KB？

显然，"分界点"将取决于情况，例如，移动网站可能会有所不同。但是，如果有人有任何有助于指导此决定的一般指示，那么我想听听。

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

（奖励点：如果内联与外部 CSS 的所有注意事项完全相同，请告诉我。

我在这里严格来说是一个性能，更多的是一个思想实验（请原谅缺乏实验严谨性）。

如果你正在内联javascript，是的，你确实节省了时间，因为一切都在一个http请求中完成。 但是，您应该考虑服务器动态生成所需网页所需的时间（SSL 也会为此增加时间）。

最佳案例

如果你可以创建一个生成缩小的javascript并将其注入html页面的构建，并结合gzip压缩，你应该导致带宽低得多。 与每个请求单独 gzip 相比，您在压缩中粘贴的文本越多，您的回报就越大。 最终，这意味着如果你可以让它静态地加载一个带有所有javascript/css的html页面，这意味着它肯定会更快。

正常情况（使用动态 html 和共享 js 库）

一些堆栈溢出帖子的一小部分示例以及它们如何影响我自己的带宽：

304ms 9.67KB
204ms 11.28KB
344ms 17.93KB
290ms 17.19KB
210ms 16.79KB
591ms 37.20KB
229ms 30.55KB

从这一点来看，似乎每个http连接产生的开销（不考虑文件大小）约为150毫秒 - 也许在最坏的情况下。 现在，问题是，文本（在你的例子中是javascript）必须有多大才能产生150ms的带宽。 根据这篇文章（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+缩小javascript下载才能与之相等。

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

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

截止点是 0KB -- "什么时候 JavaScript 足够小，值得内联"的答案是"从不"。

除了你说你不想考虑的可维护性问题之外，无论如何它对性能更好。是的，第一次引用.js文件时，您有一个额外的 HTTP 请求，但之后它会被缓存，因此您的整体流量/带宽会随着时间的推移而减少。

CSS文件也是如此。

使用内联JS或CSS使页面更重比对文件初始提取的额外请求成本更高（除非您提供完全静态.html，其中整个页面长时间缓存）

简短的回答：这取决于！

若：

  • 您不会通过实际将脚本复制并粘贴到每个 HTML 页面来内联脚本
  • 将正确缓存单独的文件

做数字。 粗略估计额外的HTML将产生多少额外的流量，与其他流量成比例，然后决定你是否认为这是一个可以接受的折衷方案。

如果是1%，可能不值得担心。 但如果它是 50%，那么您可以通过将脚本放在单独的文件中来将流量减半。

相关文章：