配了三年性能优化，每次要给动画分级都要靠猜——CPU Performance API 今天把这件事从根上原生化了

做性能优化这些年，你肯定遇到过这个场景：要给视频选清晰度，要给动画选帧率，要决定某台设备能不能跑 WebGPU——最后全靠「猜」。

猜的方法大概就两种：要么写一段 JS benchmark，计时跑个 30 帧看看卡不卡；要么直接 UA 字符串判断机型。两种都有问题：benchmark 在低端机上跑 500ms，这 500ms 本身就是卡顿；UA 嗅探不准确，跨代设备差异大，而且苹果和谷歌一直在改 UA 格式。

Chrome 152 今天把这件事彻底变了。

浏览器自己知道你的设备快不快

Chrome 152 开放了 CPU Performance API。调用方式就一行：

“`javascript
const tier = navigator.cpuPerformance;
// 1 = 低端，实际跑视频通话基本没法用
// 2 = 中低端，跑视频通话勉强能对付
// 3 = 中高端，舒适跑视频+部分特效
// 4 = 高端，性能有大量余量，可以跑满
// 0 = 浏览器无法判断等级
“`

这四个等级是怎么分出来的？不是你自己跑 benchmark 跑出来的，是浏览器根据设备 CPU 型号、核心数、频率等综合信息算出来的。Chrome 维护着一份设备数据库，返回的等级是 1~4 这个粗粒度的「性能档位」。

为什么故意粗糙？防指纹。规范要求每个等级必须覆盖 ≥10% 的现有设备型号——也就是说，就算知道了 tier，你也很难反过来定位到具体哪台机器。

比 benchmark 到底好在哪

先说 benchmark 方案的实际问题。

Mintec.co 有一个实测：在一个视频流媒体页面里跑基准测试脚本，低端机（tier 1）跑完 benchmark 要 480ms，这 480ms 里用户已经看到第一帧卡死了。而用 CPU Performance API，同样这台 tier 1 设备，API 调用是同步的，0ms 返回。

“`javascript
// 不需要跑 benchmark，直接问浏览器
function getPresetFeatures() {
const tier = navigator.cpuPerformance ?? 2; // 兜底用中低端

switch (tier) {
case 1: // 低端机：最低画质，禁用特效
return { videoQuality: “QVGA”, frameRate: 15, effects: [] };
case 2: // 中低端：中等画质，关闭实时特效
return { videoQuality: “VGA”, frameRate: 15, effects: [“voice-detection”] };
case 3: // 中高端：高清，开启部分特效
return { videoQuality: “720p”, frameRate: 30, effects: [“voice-detection”, “noise-reduction”] };
case 4: // 高端：最高画质，所有特效
case 0: // 浏览器无法判断，保守按高端处理
default:
return { videoQuality: “1080p”, frameRate: 30, effects: [“voice-detection”, “noise-reduction”, “virtual-bg”] };
}
}
“`

结合 Compute Pressure 做实时降级

CPU Performance API 回答的是「这台设备通常有多强」——一个静态值。真正做性能优化，你还需要知道「它现在忙不忙」。

这就是 Compute Pressure API 的作用。它返回 CPU 当前压力等级：nominal / fair / serious / critical。结合使用的方式是：

• 用 `navigator.cpuPerformance` 决定初始预设（静态能力）
• 用 Compute Pressure 实时监测 CPU 压力（动态状态）
• 当 Compute Pressure 达到 serious 时，自动降一档画质；当达到 critical 时，切到最低档

“`javascript
async function adaptiveVideo() {
const staticTier = navigator.cpuPerformance ?? 2;
const initialPreset = getPresetByTier(staticTier);

const observer = new PressureObserver((records) => {
const latest = records[records.length – 1];
if (latest.state === “critical”) {
video.setQuality(“QVGA”); // 紧急降级
} else if (latest.state === “serious”) {
video.setQuality(“VGA”); // 轻度降级
}
});

observer.observe(“cpu”);
return initialPreset;
}
“`

三个坑

第一个坑：Safari 不支持。 Apple 直接拒绝实现，Mozilla 投了反对票，认为会新增指纹攻击向量。目前只有 Chrome 和 Edge（Chromium 内核）支持。生产环境必须做 feature detection：

“`javascript
if (“cpuPerformance” in Navigator) {
const tier = navigator.cpuPerformance;
} else {
// fallback：使用传统 UA 判断或保守预设
}
“`

第二个坑：用户可以覆盖等级。 Chrome 允许用户在「设置 > 性能 > 速度」里手动指定 CPU 等级，企业管理员也可以用 `CpuPerformanceTierOverride` 策略强制锁定。这意味着你拿到的 tier 不一定是真 tier。需要和 Compute Pressure 交叉验证：如果你说 tier 4 但 Compute Pressure 一直是 serious/critical，说明用户在耍你或者设备被节流了。

第三个坑：等级定义是浏览器定的。 规范里说 tier 4 设备「要有余量跑多任务」，但具体哪个 CPU 型号算 tier 4 是 Chrome 自己的数据库定的。不同设备商、不同年份的设备分级标准可能会变，你的业务逻辑不能假设「tier 4 一定比 tier 3 强」。

下一步

Chrome 152 稳定版是 2026 年 8 月 25 日发布的，全球覆盖率应该在 75% 以上。如果你的用户群偏技术（Chrome 用户比例高），可以开始实验了。

第一步：打开 Chrome DevTools，在 Console 里跑 `navigator.cpuPerformance`，看看你的开发机落在哪个等级。

第二步：在你的视频或动画场景里加一行 feature detection，console.log 打印一周，看各 tier 设备的分布情况。

第三步：选一个最影响性能的模块，按 tier 写降级策略，实测低端机上的 INP 改善数据。