Core/Dash 维度： LOAF

通过将 Long Animation Frames 溯源，找出阻塞 main thread 且拉低 INP 的确切脚本 URL。

免费试用

Trusted by market leaders · Client results

nestlesnvhappyhorizonerasmusmcharvardmy work featured on web.devvpnloopearplugsmonarchwhowhatwearebaykpncomparemarktplaatsperionsaturnnina careadevintadpg mediaworkivaaleteiafotocasa

维度：Long Animation Frames (lurl)

LOAF 维度会展示在用户会话期间引发 Long Animation Frames 的脚本 URL。每个值都是一个脚本 URL：第一方 bundle、第三方分析标签、聊天小组件、同意管理器，或任何运行时间长到足以阻塞渲染的内容。这是源码级别的归因，而不是你在 DevTools 中费力重构的堆栈跟踪。

CoreDash 使用 Long Animation Frames API (LoAF) 收集此数据。Chrome 发布该 API 是为了替代旧版的 Long Tasks API。Long Tasks 只能告诉你某一帧耗时过长，而 LoAF 能告诉你该帧内运行了哪些脚本以及它们的 URL。正是这一区别，让该维度在生产环境中极具价值。

coredash loaf scripts

为什么 Long Tasks 远远不够

Long Tasks API（自 2017 年起可用）会标记任何超过 50ms 的 main thread 任务，但几乎不提供任何归因。你能看到发生了阻塞，却看不到是什么导致的。开发者要花好几个小时，将任务时间戳与网络瀑布图进行关联，猜测是哪个脚本惹的祸。

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% 的受监控资产中导致了长帧。第一方 bundle 占据了剩余部分，通常是因为 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. 应用修复并验证：对于第三方脚本，使用外观模式或延迟初始化，将其推迟到首次用户交互之后加载。对于第一方代码，在 Chrome DevTools 中将 CPU 节流设置为 4x，对特定函数进行性能分析。部署更改，并在 24-48 小时内的真实用户流量中观察 LOAF 维度的更新情况。

工程经验法则

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

LOAF 维度提供了一项任何合成测试都无法提供的东西：确凿证据，证明在生产环境中到底哪些脚本阻塞了真实用户，并按真实世界的频率排序。用它进行过滤，与你的 INP 数据进行交叉对比，你就能得到一份优先级明确的列表，清楚地知道该修什么、按什么顺序修。