我正在尝试提高网络应用程序的性能。我有一些指标可以用来优化返回 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 粉碎到每个页面加载中。

其他提示

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

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

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top