通过 Web API（导航 API 和性能时间线 API）计算前端性能指标

Posted 2023-03-31

【中文标题】通过 Web API（导航 API 和性能时间线 API）计算前端性能指标

【英文标题】：Calculating Front end performance metrics via Web API's ( navigation API and performance timeline API)

【发布时间】：2020-09-21 13:48:05

【问题描述】：

为了计算第一个内容绘制，我在浏览器控制台中使用了以下命令。

window.performance.getEntriesByType('paint') -> 从中，我获取了第一个内容绘制的开始时间：startTime: 710.1449999972829 ms。

Reference

但如果我通过 lighthouse（来自 chrome 开发工具）审核同一页面，lighthouse 计算的第一个内容绘制是 '1.5 s'

我试图了解为什么这两个数据之间存在巨大差异。尝试通过 lighthouse 运行审计几次，数据仍然与 web api 数据匹配。

谁能解释一下为什么会有巨大的差异。我应该继续使用来自 web api 的数据还是应该将灯塔数据视为有效数据？

【问题讨论】：

进行比较时，您是查看移动数据还是桌面数据？

嗨，格雷厄姆，我只查看桌面数据。

【参考方案1】：

感谢您提出的好问题，我今天因此学到了一些东西。

似乎即使在桌面视图中，CPU 也会受到一些限制，据我所知，过去并非如此。

I found this article that explains the current throttling policy.

这里的关键部分如下：

从 Chrome 80 开始，审核面板正在简化限制配置：

模拟限制仍然是默认设置。这与 PageSpeed Insights 的设置和 Lighthouse CLI 默认设置相匹配，因此提供了跨工具的一致性。 没有限制被移除，因为它会导致不准确的评分和误导性的指标结果。 在审核面板设置中，您可以取消选中 模拟限制 复选框以使用应用限制。目前，我们保留此应用限制选项可供“查看跟踪”按钮的用户使用。 在应用限制下，跟踪与指标值匹配，而在模拟下，当前不匹配。

第 3 点是主要部分。基本上，节流仍然适用于桌面上的 CPU。另请注意，他们说“暂时”，所以这显然是他们未来考虑删除的内容。

这实际上是一个非常好的主意，大​​多数开发人员都在运行功能强大的硬件，大多数消费者都在运行具有 i3 处理器（或同等...或更糟！）的廉价现成笔记本电脑。。 p>

由于 Google 会花费大量时间来完善 Lighthouse，我会将模拟限制开启并使用他们的结果，因为它们更能代表最终用户可能看到的内容。

关闭模拟节流

如果您希望跟踪结果（或控制台性能 API 结果）匹配，请取消选中页面顶部的“模拟限制”。

【讨论】：

感谢 Graham 的详细解释。但是，我仍然很困惑。我从设置中禁用了模拟限制并再次审核了页面，即使在这个时候，灯塔指标与性能选项卡中的指标匹配，但与 web api 指标不匹配。假设我必须创建一个性能自动化框架，我可以依靠从 web api 获得的数据并继续它吗？

是的，来自 Web API 的数据是准确的。您可能会看到 轻微 差异的唯一原因是完整的性能分析会占用您机器上的资源。我们是在谈论巨大的差异还是现在的差异很小？

来自 Web API 的指标 => 名称："first-contentful-paint" : startTime: 4199.144999991404 ，来自性能选项卡的 FCP 时间戳 => 时间戳 7722.0 毫秒

hmmmm，我无法在任何网站上复制这么多的差异，您是否在隐身模式下运行测试（因为某些插件可能会干扰）。除此之外，我没有想法，但正如我所说的性能 API 是准确的，所以你可以使用它。

非常感谢格雷厄姆帮助我。以下是用于计算某些指标的计算方法，请告诉我是否正确。交互时间 => Dom 交互时间 - 导航开始时间，总阻塞时间 => 第一次内容绘制 + 交互时间，页面渲染时间 => 加载事件结束时间 - domContentLoadedEventEnd 时间，页面加载时间 => 加载事件结束时间 - 导航开始时间