304延迟vs内联javascript

Question

互联网上似乎有一个普遍的结论是外部js文件更好。

主要原因是缓存，维护和可调试性。

然而，似乎没有太多关于304 http请求的开销的讨论。我去了yahoo.com，发现每个javascript文件的304都有每个文件约30毫秒的开销（主要是连接和响应开销）。

我有单独的javascript文件（解决维护问题）。我不太需要可调试性（自动化测试非常有用）。

我正在考虑是否将它们打包并内联到html文档顶部的单个脚本标记中。我知道有一点是没有意义的（当我的javascript非常大时）我应该对此进行基准测试。

我只是想知道是否有人已经根据他们得到的结果做了基准测试？

Answer 1

我也没有基准测试，这实际上也取决于你的连接延迟。但主观上我从未感受到这种潜伏期。

我还是建议拆分动态内容（你在服务器上呈现的html）和静态内容（css，js）。首先，你的html的有效负载变得更少（你节省了服务器渲染时间+有效负载更低），而且更多的是一个干净的分离，从代码的角度来看，更好的可维护性。

如果你想避免条件GET（例如通过Modified-Since或Etags标题），你也可以使用Expires标头。然后，符合标准的浏览器根本不进行http调用。

Answer 2

抱歉，我没有基准。我怀疑30ms会比拥有更大的HTML文档更糟糕，并且不得不在每次访问时重新编译JS（假设新的javascript引擎可以或将来保留并重用编译的字节码，如果JS文件被缓存的话）。

另外，这不取决于缓存策略吗？我开发的大多数网站甚至不会发出请求，如果JS文件被缓存，当然不是在浏览器会话期间，它会直接进入缓存（我知道这是因为我偶尔会接到需要按F5的客户的电话看看我的变化。）

另一个好处是有效性，将有效的JavaScript嵌入到XHTML + XML文档中并非易事。如果这是一个因素，那么拥有外部JS文件要容易得多。

您还可以分发您的JS文件并从内容分发网络提供这些文件，如果您选择将JavaScript内联到HTML中，您肯定会失去减少服务器负载的机会。

Answer 3

前一段时间我有类似的问题，并决定问两位前端性能专家@getify和@zoompf。

  

    

何时可以使用内联<script>元素？什么时候使用单独的.js文件更好？关于内联CSS和链接CSS，可以问同样的问题 - 你在哪里画线？

  

请参阅http://mathiasbynens.be/notes/inline-vs-separate-file的回复。

Answer 4

我认为通过正确设置缓存标头可以避免304个请求。

缓存控制：public，max-age = 3600

只要我们将其设置为公共，它将允许浏览器在本地缓存文件。因此它甚至不会向服务器发出请求以验证文件是否已更改一小时。

如果我们只设置

缓存控制：max-age = 3600

似乎大多数浏览器都认为他们无法缓存文件，因此每次都会检查。

对于很多js文件来说真的会增加很多开销。我会在构建时使用类似http://code.google.com/p/talifun-web/wiki/CrusherModule的东西粉碎它们，并通过添加带有文件md5哈希的查询字符串来提供带有强etag的一个js文件。因此，即使它在max-age到期之前发生变化，我们也会保留一份新文件。