9

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

我担心浏览器必须为显示的每个页面解析这些 CSS 和 JavaScript 文件,因此将站点的所有 CSS 和 JavaScript 共享到公共文件中会对性能产生负面影响。我应该尝试拆分这些文件,以便从每个页面链接到该页面所需的 CSS 和 JavaScript,还是我的努力几乎没有回报?

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

4

3 回答 3

14

上下文:虽然 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 粉碎到每个页面加载中。

于 2008-09-06T01:37:14.507 回答
3

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

于 2008-09-05T22:07:45.803 回答
2

为了补充 kamen 的出色答案,我想说在某些浏览器上,较大 js 资源的解析时间呈非线性增长。也就是说,一个 1 meg 的 JS 文件比两个 500k 的文件需要更长的时间来解析。因此,如果您的大量流量是可能将您的 JS 缓存(回访者)的人,并且您的所有 JS 文件都是缓存稳定的,那么即使您最终加载了所有这些文件,也将它们分解可能是有意义的每次浏览量。

于 2008-09-06T15:54:52.027 回答