我正在尝试提高Web应用程序的性能。我有一些指标可用于优化返回主HTML页面所需的时间，但我担心这些HTML页面中包含的外部CSS和JavaScript文件。这些是通过HTTP Expires标头静态提供的，但在应用程序的所有页面之间共享。

我担心浏览器必须为显示的每个页面解析这些CSS和JavaScript文件，因此将网站的所有CSS和JavaScript共享到公共文件中会对性能产生负面影响。我是否应该尝试分割这些文件，以便将每个页面的链接仅链接到该页面所需的CSS和JavaScript，否则我的努力会得到很少的回报？

是否有任何工具可以帮助我为此生成指标？

解决方案

回答

我相信YSlow确实可以，但是请注意，除非所有请求都通过环回连接，否则我们不必担心。除非CSS / JS文件超过几兆字节，否则拆分文件的HTTP开销对性能的影响远不止于解析。

回答

上下文：虽然HTTP开销确实比解析JS和CSS更为重要，但是忽略解析对浏览器性能的影响(即使JS不足)也是解决麻烦的好方法。

YSlow，Fiddler和Firebug并不是监视解析速度的最佳工具。除非最近进行了更新，否则它们不会将通过HTTP获取JS或者从缓存中加载JS所需的时间与解析实际JS有效负载所花费的时间分开。

解析速度有点难以衡量，但是我们在我从事的项目中已经追逐了这个指标很多次，即使使用了大约500k的JS，对页面加载的影响也很明显。显然，较旧的浏览器受害最大……希望Chrome，TraceMonkey等有助于解决这种情况。

建议：根据我们网站上的流量类型，最好分散JS有效负载，这样一来，绝不会在最受欢迎的网页上使用过的大块JS永远不会被发送到客户。当然，这意味着当新客户端访问需要此JS的页面时，我们将必须通过网络发送它。

但是，很可能会出现这样的情况，例如，由于流量模式，80％的用户永远不需要50％的JS。如果是这样，则绝对应该仅在需要JS的页面上使用较小的打包JS负载。否则，80％的用户将在每个页面加载中遭受不必要的JS解析罚款。

底线：很难找到适当的JS缓存和较小的打包有效负载之间的平衡，但是根据流量模式，除了将所有JS粉碎成每个页面加载之外，绝对值得考虑一种技术。

回答

为了增加假面的好答案，我想说在某些浏览器中，较大的js资源的解析时间呈非线性增长。也就是说，一个1兆JS文件的解析时间要比两个500k文件的解析时间更长。因此，如果访问量中有很多人可能会缓存JS(回访者)，并且我们所有的JS文件都是缓存稳定的，那么即使我们最终将所有文件都加载到该文件中，也可以将它们拆分每个综合浏览量。