Trusted by market leaders · Client results
维度：Long Animation Frames (lurl)
LOAF 维度展示了在用户会话期间导致 Long Animation Frames 的脚本 URL。每个值都是一个脚本 URL：第一方包、第三方分析标签、聊天小部件、同意管理器，或任何运行时间长到足以阻塞渲染的内容。这是在源头级别的归因，而不仅仅是您必须在 DevTools 中重建的堆栈跟踪。
CoreDash 使用 Long Animation Frames API (LoAF) 收集此数据，Chrome 将其作为旧版 Long Tasks API 的替代方案发布。Long Tasks 只能告诉您一个帧耗时过长，而 LoAF 则能告诉您在该帧内运行了哪些脚本以及它们的 URL 是什么。正是这种区别使得该维度在生产环境中非常有用。
为什么 Long Tasks 还不够
Long Tasks API（自 2017 年起可用）会标记任何超过 50ms 的主线程任务，但它几乎不提供任何归因信息。您可以看出发生了阻塞；但您无法看出是什么导致的。开发人员花费数小时将任务时间戳与网络瀑布图关联起来，猜测是哪个脚本造成的。
LoAF API 改变了这一现状。它会报告 PerformanceLongAnimationFrameEntry 对象，每个对象都包含一个 scripts 数组。该数组中的每个条目都有一个 invokerType、一个 sourceURL 以及一个 duration。CoreDash 会读取在长帧（long frame）期间运行的每个脚本的 sourceURL，并将其存储为 LOAF 维度值。结果是一个脚本 URL 排行榜，按它们在用户的长帧中出现的频率排序。
CoreDash 如何使用 LoAF 数据
每次用户交互触发长动画帧（long animation frame）时，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% 的站点中导致了 long animation frames。仅标签管理器一项，就在大约 45% 的受监控资产中造成了长帧。第一方包占据了剩余的部分，通常归因于 React 重新渲染或未优化的事件处理程序。
通过 LoAF 进行 INP 归因
INP 测量从用户交互到下一次帧绘制的时间。如果该间隙超过 200ms，Google 会将该体验归类为“需要改进”。LoAF 数据告诉您在该间隙期间运行了哪个脚本。如果 280ms 的 INP 中有 210ms 追溯到同意管理器脚本，这与 280ms 的 INP 中有 190ms 追溯到您自己的结账处理程序是完全不同的问题。修复方法不同。负责的团队不同。紧迫性也不同。
如果没有 LoAF 归因，两者在您的 INP 直方图中看起来完全相同。有了它，您可以立即将问题指派给合适的人员。
调试工作流
- 在 CoreDash 中打开 LOAF 维度：按频率（有多少次会话在长帧中看到了此 URL）排序。最顶部的条目是您的最高优先级目标。
- 与 INP 交叉过滤：将 LOAF 过滤器应用于您的 INP 指标视图。当您分离出运行了该脚本的会话时，检查 INP p75 是否发生变化。30ms+ 的增加确认了该脚本在生产环境中导致了 INP 降级。
- 分类为第一方或第三方：URL 中包含您自己的域名意味着您可以控制修复。第三方 CDN URL 意味着您需要移除、延迟加载或替换该供应商脚本。
- 应用修复并验证：对于第三方脚本，使用 facade 或延迟初始化，将其加载推迟到第一次用户交互之后。对于第一方代码，在 Chrome DevTools 中将 CPU 节流设置为 4x 来分析特定函数。部署更改并在 24-48 小时的真实用户流量内观察 LOAF 维度的更新。
工程经验法则
- 任何在超过 5% 的会话的长帧中出现的单个脚本 URL 都值得调查。按照这个比率，它已经影响了整整一个月内相当大一部分真实用户。
- 第三方脚本不应在交互处理程序期间运行。如果标签管理器在点击事件上同步触发，那是配置问题，而不是浏览器限制。
- 单个脚本长帧持续时间超过 200ms 是一个明确的信号。LoAF API 会报告帧内每个脚本的持续时间。任何消耗 200ms 或更多帧时间的脚本，都是随之而来的任何 INP 问题的首要原因。
- LOAF 列表中的第一方脚本通常指向框架开销。React、Vue 和 Angular 都可能在状态更新期间产生长帧。LoAF URL 将是您自己的包。分析组件树，而不仅仅是网络。
LOAF 维度为您提供了任何合成测试都无法提供的东西：关于哪些脚本在生产环境中阻塞真实用户的证据，并按真实世界的频率排序。通过它进行过滤，与您的 INP 数据进行交叉对比，您就能得到一份确切知道要修复什么以及按什么顺序修复的优先列表。