做了三年视频适配，今天才发现设备性能从来不是靠猜的——Chrome 152 把这件事彻底原生化了

你的视频在用户手机上卡成 PPT，第一反应是”网速不行”。但如果问题根本不在网速，而是在你没判断清楚用户设备的性能档位呢？

Chrome 152 正式带来了 CPU Performance API，navigator.cpuPerformance 让浏览器第一次光明正大地告诉开发者：用户的设备，是快是慢。

以前怎么做？UA sniffing + hardwareConcurrency + 跑 benchmark

视频会议应用在过去判断设备性能，靠的是私有浏览器扩展、跑一轮基准测试、或者用 hardwareConcurrency 配合 deviceMemory 盲猜。这些方法要么依赖非标准 API，要么浪费用户资源做无意义的预热，而且硬件参数和实际表现之间的关联并不稳定——同等核心数的 CPU，实际性能可能差两三倍。

现在一行搞定。

const tier = await navigator.cpuPerformance.getPerformanceTier();
// 返回: 0（未知）| 1（入门）| 2（中端）| 3（高端）| 4（旗舰）

粒度很粗：只有四档，外加一个”未知”。这恰恰是设计用意——不暴露具体 CPU 型号、核心数或时钟频率，防止成为 fingerprinting 向量。Google 明确说了，这比 hardwareConcurrency（约 4-5 bits 熵）加 deviceMemory 的组合更隐私。用户在 Chrome 设置里可以手动 override 这四个等级，企业管理员也可以通过 CpuPerformanceTierOverride 策略强制设定。

这四个 tier 怎么用？

视频场景最直接。WebRTC 视频会议或者点播平台，可以按 tier 选分辨率和 codec——入门机降一级，高端机开 AV1，旗舰机直接上 4K。实测数据显示，不做这个判断的情况下，p75 用户可能因为设备撑不住而反复卡顿，而不是因为网速慢。

async function selectVideoQuality() {
  const tier = await navigator.cpuPerformance.getPerformanceTier();
  const presets = {
    0: { width: 480,  codec: 'VP8' },
    1: { width: 720,  codec: 'VP8' },
    2: { width: 1080, codec: 'H.264' },
    3: { width: 1440, codec: 'H.264' },
    4: { width: 2160, codec: 'AV1' }
  };
  return presets[tier] ?? presets[1];
}

WebGPU 也是受益者。GPU 性能差异比 CPU 大得多，同一款设备，高级GPU和集成显卡的帧率可能差出十倍。可以用这个 tier 来决定 shader 复杂度或是否降级到 WebGL2。

const tier = await navigator.cpuPerformance.getPerformanceTier();
const maxTextureSize = tier >= 3 ? 8192 : 4096;

WebLLM 的模型选择更直观。跑本地大模型，Tier 1-2 的设备用 3B 参数模型，Tier 3-4 上 7B-13B 模型，体验比跑不动然后降级要好得多。

最后补一个实战细节：

CPU Performance API 回答的是”这台设备有多强”（静态），Compute Pressure API 回答的是”CPU 现在忙不忙”（动态）。两者组合才是完整方案——先用 Performance Tier 选初始预设，再用 Compute Pressure 实时降级或恢复。

Chrome 152（2026年8月25日稳定版）覆盖率约 88%。Safari 的态度是”No signal”，目前不支持。渐进增强写法：

const tier = ('cpuPerformance' in navigator)
  ? await navigator.cpuPerformance.getPerformanceTier()
  : 1; // fallback 默认中端

下一步：把 getPerformanceTier() 接入你的视频适配层，或者加进 WebGPU 初始化逻辑里做能力探测。