你以为 Performance API 只能查 timing？Chrome 154 把这两件事彻底放出来了

你在调试性能问题的时候，第一反应是打 log 还是翻 DevTools？大多数前端工程师眼里，performance.now() 和那个 Performance 面板就是这组 API 的全部了。

这个印象不能说错，但已经严重过时了。

Chrome 154（2026 年 9 月正式版）把两件事彻底放进了这个 API 里——一件让浏览器自己替你跑 profiler，另一件让你在线上量到页面真实吃掉的全部内存。两件加起来，就是过去十年前端性能监控缺的两个角。

第一件：浏览器自己会跑 profiler 了

JS Self-Profiling API 干的事情，是让浏览器把自己的采样 profiler 直接暴露给 JavaScript。

以前你想知道 JS 执行时间花在哪了，选项就两个：DevTools Performance 面板（人工操作，无法自动化），或者自己插 mark/measure（精确但只能覆盖你手动埋的点）。

现在三行代码：

const profiler = new Profiler({ sampleInterval: 10, maxBufferSize: 10000 });
// 你的业务代码
const trace = await profiler.stop();
console.log(JSON.stringify(trace));

profiler.stop() 返回的结构长这样：frames（函数位置）、stacks（调用栈）、samples（时间戳+栈 ID）。采样间隔 10ms，缓冲 10000 条。统计意义上，你知道哪个函数吃掉了最多采样次数——也就是最需要优化的那个。

这个 API 牛的地方在于它是采样 profiler，不是插桩 profiler。采样间隔 10ms 开销极低，不影响被测代码的真实执行时间。你可以在生产环境里以 5 秒为单位做采样，把 trace 发到自己的分析平台。

有一个前提：页面必须通过 Document Policy 声明 js-profiling 这个配置点。换句话说，这不是一个随便什么第三方脚本都能用的 API——只有你的第一方代码才能开 profiler。安全边界是故意这么设计的，防止恶意脚本偷跑 profiler 收集指纹。

第二件：终于可以量到页面真实的内存了

performance.measureUserAgentSpecificMemory() 这个名字长得令人窒息，但它解决了一个老问题。

以前你用什么量内存？performance.memory，返回 usedJSHeapSize。这组数字有三个致命问题：

第一，只量 JS 堆。DOM 节点、iframe、Worker 占的内存全不算。第二，共享堆噪声。同源多个页面跑在一个渲染进程里，你拿到的数字可能把别人的内存也算进来了。第三，即时快照。GC 还没跑，数字虚高，而且是非标准 API。

新 API 怎么不一样？

const result = await performance.measureUserAgentSpecificMemory();
console.log(result);
// { bytes: 5000000, breakdown: [...] }

返回 Promise，在 GC 之后测量，覆盖 JS + DOM + iframe + Worker，而且按页面隔离归因。breakdown 里每一项都有 attribution（哪个 URL，哪个 scope）和 types（JS/DOM/GPU/Code）。

它有一个门槛：页面必须处于跨源隔离（Cross-Origin Isolation）状态。为什么？因为内存归因需要精确知道「这块内存属于哪个来源」，没有隔离就泄露细粒度信息，可能变成 Spectre 的帮凶。COOP + COEP 响应头是入门的最低配置。

真实使用场景

这两个 API 组合起来是什么感觉？

profiler API 适合在用户操作过程中触发——比如点击了某个按钮之后，采样 5 秒，把 trace 发走。你能知道用户实际遇到了哪个函数的性能瓶颈，而不是靠 Lighthouse 猜。

memory API 适合在页面生命周期里定期调用——比如每 30 秒量一次内存，相减得到增量。如果你发了新版本，这个增量突然涨了 40%，你就有数据说「这次发布引入了内存泄漏」。

两者结合，就是从「我知道页面卡」到「我知道哪行代码让页面卡」，以及从「页面内存好像变大了」到「精确知道哪个模块吃了多少内存」。

Chrome 154 之前的现状

目前 JS Self-Profiling API 还在实验阶段，需要通过 document policy 开启。measureUserAgentSpecificMemory 已经在 Chrome 89+ 稳定，但跨源隔离的门槛让它在中小企业项目里落地率极低。

这两个 API 的共同特点是「前提条件严格」——它们不是那种加个 polyfill 就能用的东西。但一旦你的基础设施支持，它们解决的是以前根本没法自动化解决的问题。

你的下一步

如果你的页面还没配 COOP/COEP，现在就去加上。跨源隔离不只是为了这个 API，它同时也是防 Spectre 攻击的基础。然后在你的监控平台里埋两个定时任务：一个是 profiler 采样（按需触发），一个是内存增量监控（定期）。数据积累一个月，你会发现自己对性能问题的判断方式完全变了。

Performance API 不只是 timing。Chrome 154 把它的边界推到了 profiler 和 memory 两个方向。这两件事，前端监控的账，在 2026 年终于开始算清楚了。