写过视频会议的人都踩过这个坑——每次接进来的人，要么画面糊成一团马赛克，要么特效全开把设备跑成暖手宝

写过视频会议的人都踩过这个坑——每次接进来的人，要么画面糊成一团马赛克，要么特效全开把设备跑成暖手宝。产品经理问能不能按机型做适配，工程师只能苦笑：User-Agent 写死的，谁知道这台设备到底能跑成什么样。

Chrome 152 干了一件浏览器从来没干过的事：直接告诉你用户的设备大概是什么档次。

这个 API 长什么样：

const tier = navigator.cpuPerformance;
// 返回 0、1、2、3、4 其中之一
// 0 = 分类失败（当 tier 4 处理）

0 到 4，五个等级，每个等级对应一类设备：

Tier 1：基本打不了视频通话，QVGA 15fps，特效一个都别想开
Tier 2：能通话但吃力，VGA 15fps，可以开语音检测和简单动效
Tier 3：流畅通话，720p 30fps，语音检测、动效、降噪都能上
Tier 4：性能绰绰有余，1080p 30fps，虚拟背景随便开

视频会议应用直接 switch 一下就能选预设。

它是怎么算出来的：

这个值不是玄学。Chrome 的实现逻辑大致是：

1. 读逻辑核心数
2. 只有一个核 → Tier 1
3. 2-4 核 → 对照一张老旧 Atom 类 CPU 黑名单，被命中的降成 Tier 1，现代高效四核（Ryzen、Gracemont、Apple M 系列）升到 Tier 3
4. 5-10 核 → Apple M 系列或 Intel Core Ultra（8 核及以上）→ Tier 4，否则 Tier 3
5. 10 核以上 → 无条件 Tier 4

频率（GHz）不在评估维度里，所以不是 MHz 越高越好，而是核心架构和核心数量说了算。

它不只是在选画质：

静态的 Tier 只能回答这个设备强不强，动态的负载才能回答它现在累不累。这两个问题需要两个 API 组合起来。cpuPerformance 用来决定默认开还是关，PressureObserver 用来运行时动态调整。静态加动态，才是完整的设备适配方案。

它的隐私设计：

这个 API 故意很糙：只有 5 个桶，不暴露 CPU 型号、不暴露核心数、不暴露频率。规范要求每个桶必须覆盖市面上不少于 10% 的设备，防止通过这个值做指纹识别。

此外，用户可以在 Chrome 设置里手动覆盖这个值，企业也可以通过 CpuPerformanceTierOverride 策略强制指定。

接下来怎么用：

如果你做的是媒体类、功能类、性能敏感类的 Web 应用，这个 API 值得现在就看一眼。主要适用场景：

• 视频会议：开局就选对画质档位
• 在线游戏：决定要不要加载粒子特效
• 设计工具：判断要不要生成实时预览
• 广告视频：决定播放器里塞不塞互动层

Chrome 152 已经在跑两周一个版本的节奏，这个 API 随着稳定版推送会覆盖越来越多设备。搭配 Compute Pressure API 做实时调控，用户体验和设备续航能同时顾到。

下一步：翻一下你现在产品里哪些地方靠 UA 字符串或者 Device Memory API 猜设备能力，把它们换成 navigator.cpuPerformance，代码干净很多，分类也比以前准。