Core/Dash 维度： LOAF

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

免费试用

Trusted by market leaders · Client results

perionvpndpg mediawhowhatwearmonarchsaturnfotocasaworkivacompareadevintaloopearplugsharvardebaysnvmy work featured on web.devnestlehappyhorizonaleteianina carekpnmarktplaatserasmusmc

维度：长动画帧 (lurl)

LOAF 维度展示了在用户会话期间引发长动画帧的脚本 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 年起可用）会标记任何超过 50 毫秒的主线程任务，但它几乎不提供任何归因。您可以看出发生了阻塞；但您无法看出是什么引起的。开发人员花费数小时将任务时间戳与网络瀑布流相关联，以此猜测是哪个脚本造成的。

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

如果没有 LoAF 归因，两者在您的 INP 直方图中看起来完全相同。有了它，您可以立即将问题路由给合适的人员。

调试工作流

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

工程经验法则

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

LOAF 维度为您提供了任何合成测试都无法提供的信息：关于哪些脚本在生产环境中阻塞了真实用户的证明，并按真实世界的频率进行了排名。对其进行过滤，与您的 INP 数据进行交叉引用，您就能获得一个包含确切修复内容和修复顺序的优先列表。