你以为设备卡不卡只能靠盲猜？今天浏览器把这件事用 API 透明了

用户跟你说「页面卡」，你打开 DevTools 看了一圈：CPU 占用正常，内存没爆，Lighthouse 跑分良好。你也不知道哪里卡。但设备知道。

Chrome 125 稳定版开始，Compute Pressure API 正式落地。这个 API 做的事很简单：持续告诉你设备 CPU 当前处于哪个压力状态。四个状态，含义清晰：

• nominal：一切正常，CPU 没在干什么重活
• fair：CPU 在干活了，风扇可能开始响，但设备跑得动
• serious：持续高负载，系统可能开始主动降频
• critical：温度警戒，设备需要降温，否则性能会断崖

这四个状态不是硬件发烧友的自嗨，是真正能落地到交互决策的信号。

为什么这件事以前做不了

前端判断设备能力，业界传统做法是两件事：要么用 navigator.hardwareConcurrency 读 CPU 核心数做预估，要么直接靠用户投诉来发现问题。前者只能告诉你「设备理论上有多少条命」，后者只能告诉你「出事了」。中间那段——「设备现在有多忙、接下来会不会扛不住」——一直是黑的。

Chrome 团队解决这个问题分了两步：

• Chrome 152 给出 navigator.cpuPerformance：一个静态的 1-4 tier，告诉你「这台设备属于哪一档」
• Chrome 125 给出 PressureObserver：实时的、持续的状态推送，告诉你「CPU 现在有多忙」

这两件事合起来，才是一个完整的答案：设备性能上限用 CPU Performance API 摸清楚，运行时压力用 Compute Pressure API 监控起来。

实际代码长这样

const observer = new PressureObserver((records) => {
  const state = records[records.length - 1].state;
  if (state === critical) {
    document.body.classList.add(ultra-reduced);
  } else if (state === serious) {
    document.body.classList.add(reduced);
  } else {
    document.body.classList.remove(reduced, ultra-reduced);
  }
}, { sampleInterval: 2000 });

observer.observe(cpu);

状态切到 serious 就降画质，切到 critical 就保基本功能。用 CSS 类名控制降级逻辑，工程师不用在每个组件里写 if-else。

能落地到哪里

视频会议应用：进入 serious 状态时自动降码率，进入 critical 时切换到语音模式，用户感知到的是「它很智能」，而不是「又崩了」。

WebGL 游戏：根据压力状态动态调渲染分辨率，而不是等到帧率掉到个位数才反应过来。

在线地图：检测到设备处于高压力状态时，临时关闭矢量图标的实时效果，保证导航操作本身是流畅的。

测得到才能管得了

用 Compute Pressure 做优化，测量维度要换：不再是「某个功能加载快不快」，而是「设备在 nominal 状态下花了多少时间、触发了多少次 serious 和 critical」。

这两个指标直接挂钩用户主观体验：critical 触发次数越少，用户越不会觉得「这应用真卡」。

下一步怎么做

如果你现在维护的是媒体类、地图类、游戏类应用，把 Compute Pressure API 纳进你的性能监控体系：

1. 先用 CPU Performance API 的 tier 做初始质量档位预设
2. 再用 PressureObserver 监听状态变化，动态调整
3. 记得 fallback：Firefox 和 Safari 目前不支持，通过 @supports (type: PressureObserver) 做渐进增强

浏览器兼容：Chrome 125+、Edge 125+。Firefox 和 Safari 暂不支持，但有明确的 feature detection 方案。

API 不复杂，复杂的是想到用它——毕竟在它出现之前，「设备现在有多忙」这件事，对网页来说一直是个黑箱。