用户说页面卡，Lighthouse 绿了三年——今天 LoAF API 把根子扒出来了

你页面慢，用户说卡，Lighthouse 分数却绿了——这种割裂感盯了三年，今天 LoAF API 终于把根子扒出来了。

Long Animation Frame API（LoAF，读作 Lo-Af）是 Chrome 123 正式推出的性能监测 API，它的核心能力是：汇报每个超过 50ms 的帧是谁造成的。

以前的 Long Tasks API 只能告诉你「有个任务很慢」，LoAF 升级在两处：一是拿到帧里具体执行了哪些脚本的耗时分布，二是能关联到具体是哪个长交互导致的 INP（Interaction to Next Paint）超标。等于把「哪个用户在哪个操作上感受到了卡顿」这件事，直接量化出来。

接进来其实不复杂，一个 PerformanceObserver 就够了：

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log("Long frame:", {
      duration: entry.duration,
      scripts: entry.scripts?.map(s => ({
        name: s.name,
        duration: s.duration
      }))
    });
  }
});
observer.observe({ type: "long-animation-frame", buffered: true });

实际跑起来，生产环境能拿到这样的数据：某个「点击提交按钮后弹出 Modal」的操作，INP 超标到 600ms，LoAF 汇报出来根因是 Modal 里的第三方 SDK 初始化占用了 380ms——Lighthouse 跑 synthetic test 根本跑不到这个场景。

这就是真实用户体验监控和实验室数据的根本区别：Lighthouse 是固定网络、模拟用户，而 LoAF 拿到的是真实用户在真实设备上的真实帧数据。

某电商团队接了 LoAF + INP 监控链路后，把结算页的 INP 从 410ms 压到 135ms，靠的不是换 CDN 或者加缓存，是逐帧分析发现「促销弹层初始化阻塞了主线程」——这个问题 Lighthouse 跑了两年都是绿的。

下一步：在你的前端监控里加一行 PerformanceObserver，把长帧数据上报到 APM 系统。INP 超标的时候，先别急着加缓存，先看看 LoAF 报出来的根因是不是代码层面的问题——很多情况下，真正的瓶颈根本不在网络上。