304延迟与内联JavaScript

Question

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

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

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

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

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

我只是想知道是否有人已经对此进行了基准测试，并得到了什么样的结果？

- Brian Takita

Answer 1

我也没有基准，这主要取决于您的连接延迟。但是主观上，我从未感觉到这种延迟。

不过，我建议将动态内容（在服务器上呈现的HTML）和静态内容（CSS、JS）分开。首先，您的HTML负载会大大降低（您可以节省服务器渲染时间+负载更低），此外，这是一种清晰的分离，从代码角度来看更易于维护。

如果您想避免有条件的GET请求（例如通过Modified-Since或Etags标头），您还可以使用Expires标头。符合规范的浏览器根本不会发出HTTP调用。

- manuel aldana

---

避免条件GET看起来不错。此外，可以对JavaScript文件进行版本控制以使缓存过期。https://dev59.com/r3E95IYBdhLWcg3watM3 - Brian Takita

Answer 2

抱歉，我没有基准数据。我怀疑30毫秒的速度并不比拥有更大的HTML文档并且每次访问都需要重新编译JS文件（假设新的JavaScript引擎可以或将来会保留和重用已缓存的字节码）更差。

此外，这不取决于缓存策略吗？我开发的大多数网站甚至不会在JS文件被缓存时发出请求，当然也不会在浏览器会话期间发出请求，它会直接到缓存中（我知道这一点是因为我偶尔会接到客户的电话，他们需要按F5才能看到我的更改）。

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

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

- Lee Kowalkowski

---

似乎总是有一个HTTP请求（至少在Firefox中），使用expires头。如果缓存仍然有效，服务器将响应304。此外，JS每次都需要重新解释吗？我认为缓存的节省只会在数据传输方面。关于CDN和有效性的观点很好。 - Brian Takita

对于基于解释的引擎来说是可以这样，但是比如 V8 就会将 JavaScript 编译成原生机器码。如果 JS 文件已经被缓存了，那么浏览器就没有必要重新编译它。而 HTML 中嵌入的 JS 不太可能被缓存。我不知道这样的浏览器是否会无论如何重新编译 JS，但如果今天他们这样做了，未来可能就不会了。 - Lee Kowalkowski

Answer 3

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

cache-control:public, max-age=3600

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

如果我们仅设置

cache-control: max-age=3600

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

对于很多增加了很多开销的js文件，我建议在构建时使用像http://code.google.com/p/talifun-web/wiki/CrusherModule这样的东西来压缩它们，并添加一个查询字符串和文件md5哈希值的强etag来提供一个js文件。所以，即使在max-age到期之前更改了文件，我们也能保证获得新鲜的文件。

- Taliesin

Answer 4

我之前有一个类似的问题，于是决定向前端性能专家@getify和@zoompf请教。

什么情况下使用内联<script>元素是可以接受的？何时最好使用单独的.js文件？同样的问题也可以问到内联与链接CSS之间的区别——你如何划分界限？

请参阅http://mathiasbynens.be/notes/inline-vs-separate-file以了解他们的回答。

- Mathias Bynens