【问题标题】:How to use Network's Waterfall in Chrome Dev Tool to diagnose web rendering performance issue?如何在 Chrome Dev Tool 中使用 Network's Waterfall 来诊断 Web 渲染性能问题?
【发布时间】:2017-07-25 03:12:15
【问题描述】:

我们的一个网页存在渲染性能问题,当页面打开时,微调器冻结或加载非常缓慢,并且在 6-12 秒后页面完成加载。所以我在 chrome 开发工具中使用网络的瀑布来诊断问题。但是我遇到了一些我不明白发生了什么的情况。

在下面的截图中,对应页面的所有资源都在很短的时间内加载完毕,但是微调器冻结了 6 秒或 9 秒,我不确定资源加载之后和之前发生了什么页面完成加载,也许微调器在错误的线程中或以某种方式被阻止?我应该用什么方法来查明原因?

场景 1

场景 2

更新

网络截图

时间线截图

更新

检查事件日志后,我认为问题发生在 Angular 摘要周期,端点响应时间仍应为 780 毫秒。

【问题讨论】:

  • @wOxxOm 感谢您的回复。我添加了一个带有网络截图和时间线截图的场景,在网络中突出显示的请求需要 780 毫秒,但在时间线上大约需要 8 秒。这是为什么呢?
  • 我对这些问题的回答不是很熟练,没有看到网站,请尝试在此处等待答案的同时找到一些有关使用时间线工具的教程。

标签: google-chrome-devtools web-performance


【解决方案1】:

感谢您提供详细信息。如果您可以链接到该页面会更有帮助,但我知道这通常是不可能的。我只会为同一条船上的人提供一些一般数据。不过,我不知道我是否能够完全回答这个具体问题。

场景 1场景 2 屏幕截图中,您可以看到资源在 1 或 2 秒内加载完毕。这是您的暗示,该问题与网络无关。

因此,虽然这是一个页面加载问题,但与网络无关。

时间线截图中,您可以看到您的 CPU 使用率从大约 1900 毫秒到超过 16000 毫秒已完全达到最大值。所以你的页面迫使浏览器做大量的工作。这可能在 JavaScript 中。

为了诊断这个问题,我会调查火焰图(在 Main 下),您可以在 Timeline Screenshot 中看到它。条形越长,完成该功能所需的时间就越长。或者,如果您看到一个小函数被调用了数千次,这可能就是原因。如果您可以优化这些调用,那么您可以更快地加载您的页面。您可以点击 UPDATE 屏幕截图中的 Self Time 标题,根据耗时最长的函数调用排名。

再说一次,我不知道这个答案对这个特定问题有多大帮助,但我想我会尝试以不同的、更一般的方式重新表述这个问题。

【讨论】:

  • 感谢您的回复!我要确认的一件事是,我应该查看 Self Time 还是 Total Time?因为 Self Time 都是非常小的数字,不到 30 毫秒。
  • Self Time 是直接在该函数中花费的时间。 Total Time 是在该函数以及它调用的任何函数中花费的时间。所以他们都可以提供帮助。
猜你喜欢
  • 2018-10-31
  • 2017-06-19
  • 1970-01-01
  • 2018-01-19
  • 1970-01-01
  • 1970-01-01
  • 2014-06-26
  • 2020-05-02
  • 1970-01-01
相关资源
最近更新 更多