我正在尝试提高 Web 应用程序的性能。我有一些指标可以用来优化返回主 HTML 页面所需的时间，但我担心这些 HTML 页面中包含的外部 CSS 和 JavaScript 文件。这些是静态服务的，带有 HTTP Expires 标头，但在应用程序的所有页面之间共享。
我担心浏览器必须为显示的每个页面解析这些 CSS 和 JavaScript 文件，因此将站点的所有 CSS 和 JavaScript 共享到公共文件中会对性能产生负面影响。我应该尝试拆分这些文件，以便从每个页面链接到该页面所需的 CSS 和 JavaScript，还是我的努力几乎没有回报？
是否有任何工具可以帮助我为此生成指标？
上下文：虽然 HTTP 开销确实比解析 JS 和 CSS 更重要，但忽略解析对浏览器性能的影响（即使你的 JS 不到一兆）是让自己陷入困境的好方法。
YSlow、Fiddler 和 Firebug 并不是监控解析速度的最佳工具。除非它们最近已更新，否则它们不会将通过 HTTP 获取 JS 或从缓存加载所需的时间与解析实际 JS 有效负载所花费的时间分开。
解析速度有点难以衡量，但我们已经在我从事的项目中多次追踪这个指标，即使使用约 500k 的 JS，对页面加载的影响也很显着。显然，较旧的浏览器受到的影响最大……希望 Chrome、TraceMonkey 等有助于解决这种情况。
建议：根据您网站上的流量类型，拆分您的 JS 有效负载可能非常值得您花时间，因此永远不会在最受欢迎的页面上使用的一些大块 JS 永远不会发送到客户。当然，这意味着当一个新的客户端点击一个需要这个 JS 的页面时，你必须通过网络发送它。
但是，很可能会出现这种情况，比如说，由于您的流量模式，您的 80% 的用户永远不需要您的 50% 的 JS。如果是这样，您绝对应该只在需要 JS 的页面上使用更小的、打包的 JS 有效负载。否则 80% 的用户将在每次页面加载时遭受不必要的 JS 解析惩罚。
底线：很难找到 JS 缓存和更小、打包的有效负载之间的适当平衡，但根据您的流量模式，绝对值得考虑一种技术，而不是将所有 JS 粉碎到每个页面加载中。
我相信YSlow确实如此，但请注意，除非所有请求都通过环回连接，否则您不必担心。拆分文件的 HTTP 开销对性能的影响远远超过解析，除非您的 CSS/JS 文件超过几兆字节。
为了补充 kamen 的出色答案，我想说在某些浏览器上，较大 js 资源的解析时间呈非线性增长。也就是说，一个 1 meg 的 JS 文件比两个 500k 的文件需要更长的时间来解析。因此，如果您的大量流量是可能将您的 JS 缓存（回访者）的人，并且您的所有 JS 文件都是缓存稳定的，那么即使您最终加载了所有这些文件，也将它们分解可能是有意义的每次浏览量。