Core/Dash 维度： LOAF

通过将长动画帧 (Long Animation Frames) 归因于其源头，找到阻塞主线程并降低 INP 的确切脚本 URL。

免费试用

Trusted by market leaders · Client results

aleteialoopearplugswhowhatwearadevintanestlemarktplaatssaturnhappyhorizonmy work featured on web.devcompareperionkpndpg mediaworkivamonarchharvarderasmusmcfotocasavpnebaynina caresnv

维度：长动画帧 (lurl)

LOAF 维度展示了在用户会话期间导致长动画帧 (Long Animation Frames) 的脚本 URL。每个值都是一个脚本 URL：第一方包、第三方分析标签、聊天小部件、同意管理器，或者是任何运行时间过长而阻塞渲染的脚本。这是在源码级别的归因，而不仅仅是您必须在 DevTools 中重构的堆栈跟踪。

CoreDash 使用 Long Animation Frames API (LoAF) 收集这些数据，这是 Chrome 作为旧版 Long Tasks API 的替代方案提供的。Long Tasks 只能告诉您一个帧耗时过长，而 LoAF 可以告诉您该帧内运行了哪些脚本以及它们的 URL 是什么。正是这种区别使得该维度在生产环境中非常有用。

coredash loaf scripts

为什么 Long Tasks 远远不够

Long Tasks API（自 2017 年起可用）会标记任何超过 50ms 的主线程任务，但它几乎不提供任何归因信息。您只能看到发生了阻塞，却看不到是什么引起的。开发人员要花几个小时将任务时间戳与网络瀑布流相关联，以此来猜测哪个脚本是罪魁祸首。

LoAF API 改变了这一状况。它报告 PerformanceLongAnimationFrameEntry 对象，每个对象包含一个 scripts 数组。该数组中的每个条目都有一个 invokerType、一个 sourceURL 和一个 duration。CoreDash 会读取在长帧期间运行的每个脚本的 sourceURL，并将其作为 LOAF 维度值存储。结果将是一个脚本 URL 的排名列表，按它们在用户的长帧中出现的频率进行排序。

CoreDash 如何使用 LoAF 数据

每次用户交互触发长动画帧时，CoreDash 都会将导致该情况的脚本 URL 与 INP 观察结果一起记录下来。这意味着您可以按 LOAF URL 过滤 INP 数据，并查看哪个脚本对您最糟糕的交互体验负责。该维度按 URL 分组，因此您可以看到有多少会话涉及该脚本引起长帧的计数。

您将在 LOAF 维度中看到的典型条目：

  • https://www.googletagmanager.com/gtm.js (Google Tag Manager 容器)
  • https://cdn.cookielaw.org/consent/... (OneTrust 或类似的同意平台)
  • https://js.intercomcdn.com/... (聊天小部件)
  • /static/js/app.bundle.js (您自己的应用程序代码)
  • https://connect.facebook.net/en_US/fbevents.js (Meta Pixel)

在 CoreDash 数据中，第三方脚本在约 60-70% 的网站中导致了长动画帧。在受监控的资产中，仅标签管理器就导致了大约 45% 的长帧。第一方包占据了剩余部分，这通常是由于 React 重新渲染或未优化的事件处理程序引起的。

通过 LoAF 进行 INP 归因

INP 测量从用户交互到下一帧绘制的时间。如果该间隙超过 200ms，Google 会将该体验归类为“需要改进”。LoAF 数据告诉您在该间隙期间运行了哪个脚本。一个 280ms 的 INP 中有 210ms 追溯到同意管理器脚本，与一个 280ms 的 INP 中有 190ms 追溯到您自己的结账处理程序，是完全不同的问题。修复方法不同。负责团队不同。紧急程度也不同。

如果没有 LoAF 归因，两者在您的 INP 直方图中看起来完全相同。有了它，您可以立即将问题转交至正确的人员。

调试工作流

  1. 在 CoreDash 中打开 LOAF 维度：按频率（有多少会话在一个长帧中看到了该 URL）进行排序。顶部的条目是您的最高优先级目标。
  2. 与 INP 交叉过滤：将 LOAF 过滤器应用于您的 INP 指标视图。检查在隔离运行该脚本的会话时，INP p75 是否发生变化。如果增加了 30ms+，则可确认该脚本正在导致生产环境中的 INP 降低。
  3. 区分为第一方或第三方：URL 中出现您自己的域名意味着您可以控制修复。第三方 CDN URL 则意味着您需要移除、延迟加载或替换该供应商的脚本。
  4. 应用修复并验证：对于第三方脚本，使用外观模式 (facade) 或延迟初始化将其延迟到首次用户交互之后加载。对于第一方代码，在 Chrome DevTools 中将 CPU 节流设置为 4x，分析特定函数。部署更改，并观察 LOAF 维度在 24-48 小时的真实用户流量中的更新情况。

工程经验法则

  • 任何在超过 5% 的会话的长帧中出现的单个脚本 URL 都值得调查。在这种频率下，它已经在一个月内影响了相当比例的真实用户。
  • 第三方脚本不应该在交互处理程序期间运行。如果标签管理器在点击事件中同步触发，那就是配置问题，而不是浏览器限制。
  • 单个脚本的长帧持续时间超过 200ms 就是一个明确的信号。LoAF API 报告帧内每个脚本的持续时间。任何消耗 200ms 或更多帧时间的脚本，都是其后所有 INP 问题的首要原因。
  • LOAF 列表中的第一方脚本通常指向框架的性能开销。React、Vue 和 Angular 都可能在状态更新期间产生长帧。LoAF URL 将会是您自己的包。不仅要分析网络，还要分析组件树。

LOAF 维度为您提供了综合测试无法提供的东西：按真实频率排名的、在生产环境中阻塞真实用户的脚本证据。按其进行过滤，与您的 INP 数据交叉对比，您将获得一份针对确切修复内容及其顺序的优先级列表。