互联网上似乎有一个普遍的结论，即外部 js 文件更好。
主要原因是缓存、维护和可调试性。
但是似乎没有太多关于 304 http 请求的开销的讨论。我去了 yahoo.com，发现每个 javascript 文件的 304 对每个文件有大约 30 毫秒的开销（主要是连接和响应开销）。
我有单独的 javascript 文件（解决维护问题）。我不太需要可调试性（自动化测试非常有用）。
我正在考虑是否将它们打包并内联到 html 文档顶部的单个脚本标记中。我知道有一点没有意义（当我的 javascript 非常大时），我应该对此进行基准测试。
我只是想知道是否有人已经对此进行了基准测试，他们得到了什么样的结果？
【问题讨论】：
标签： javascript html http performance
我也没有基准测试，这也取决于您的连接延迟。但主观上我从来没有感觉到这种延迟。
我仍然建议拆分动态内容（您在服务器上呈现的 html）和静态内容（css、js）。首先，您的 html 的有效负载变得更少（您节省了服务器渲染时间 + 有效负载更低），而且它是一个干净的分离，从代码的角度来看更易于维护。
如果您想避免条件 GET（例如通过 Modified-Since 或 Etags 标头），您还可以使用 Expires 标头。然后，符合标准的浏览器根本不会进行 http 调用。
【讨论】：
抱歉，我没有基准。我怀疑 30ms 会比拥有更大的 HTML 文档并且每次访问都必须重新编译 JS 更糟糕（假设如果 JS 文件被缓存，新的 javascript 引擎可以或将在未来保留和重用已编译的字节码）。
另外，这不取决于缓存策略吗？如果 JS 文件被缓存，我开发的大多数网站甚至不会发出请求，当然不是在浏览器会话期间，它会直接进入缓存（我知道这一点，因为我偶尔会接到需要按 F5 的客户的呼叫查看我的更改）。
另一个好处是有效性，将有效的 JavaScript 嵌入到 XHTML+XML 文档中并非易事。如果这是一个因素，那么拥有外部 JS 文件会容易得多。
您还可以分发您的 JS 文件并从内容分发网络提供它们，如果您选择将 JavaScript 内联到 HTML 中，您肯定会失去这个减少服务器负载的机会。
【讨论】：
前段时间我有一个类似的问题，并决定询问@getify 和@zoompf，这两位前端性能专家。
什么时候可以使用内联
<script>元素？什么时候最好使用单独的.js文件？关于内联 CSS 和链接 CSS 可以问同样的问题——你在哪里画线？
请参阅http://mathiasbynens.be/notes/inline-vs-separate-file 了解他们的回复。
【讨论】：
我认为通过正确设置缓存标头可以避免 304 请求。
cache-control:public, max-age=3600
只要我们将其设置为公开，它将允许浏览器在本地缓存文件。因此它甚至不会向服务器发出请求以验证文件是否已更改一小时。
如果我们只设置
缓存控制：max-age=3600
好像大部分浏览器会认为不能缓存文件，所以每次都会检查。
至于大量的 js 文件确实增加了很多开销。我会在构建时使用http://code.google.com/p/talifun-web/wiki/CrusherModule 之类的东西粉碎它们，并通过添加带有文件的 md5 哈希的查询字符串来提供一个具有强 etag 的 js 文件。因此，即使文件在 max-age 到期之前发生更改，我们也能保证得到一个新文件。
【讨论】：