页面在低端机上卡成PPT，你以前只能靠猜——Chrome 152 把这个判断信号直接给了你

用户说页面在低端机上卡，你以前只能靠猜测——看 UA、跑微基准、猜硬件参数。Chrome 152 把这件事变了：浏览器现在直接告诉你设备大概能扛多少活。

8 月 25 日，Chrome 152 稳定版正式引入了 CPU Performance API，暴露 navigator.cpuPerformance，返回一个 0 到 4 的性能分级。0 表示无法判断，1 是入门级设备，4 是旗舰性能。这不是一个精确的 CPU 型号，也不是核数，而是一个浏览器内部基于已知硬件分类出来的粗粒度信号。它解决的是一个真实的痛点：网络适配早已成熟，但计算能力适配长期缺位。一个千元机在光纤环境下能秒下 4K 视频，解码却直接卡成 PPT；你很难仅凭网络条件判断用户能否流畅跑 WebGPU 着色器、1080p 虚拟背景，或是复杂列表动画。过去开发者要么用 navigator.hardwareConcurrency 和 deviceMemory 拼设备画像， privacy 风险高不说，信号还太细，容易被拿来 Fingerprinting；要么在页面里跑微基准测算力，成本是 50-100ms 的 JS 执行，在最不该卡的时候卡，直接抬高 INP。CPU Performance API 的定位就是填补这个空档：它给的是一个”够用就好”的粗分级，而不是可被用来追踪用户的精确硬件指纹。官方文档和 WICG spec 都明确要求每个 tier 至少要覆盖 10% 以上的设备，并且不允许暴露具体 CPU 型号或主频。用户还可以在 Chrome 设置里手动覆写这个值，企业管理员也能通过 CpuPerformanceTierOverride 策略统一控制。

Chrome 152 稳定版已上线，官方文档把它和 Compute Pressure API 配对使用：前者决定”先加载什么”，后者决定”运行时要不要降级”。真正有意思的是生产侧的用法。媒体站点 Mintec 已经把这套 API 落到了视频体验分级上：根据 navigator.cpuPerformance 返回的 tier，动态决定视频分辨率、帧率、特效和 WebGPU 负载。Tier 1 设备只给 720p/15-24fps，关闭 WebGPU 和动画模糊；Tier 2 给 1080p 降码率，保留轻量 CSS 特效；Tier 3 开放 1080p-1440p 和中等特效；Tier 4 才给 1080p/30fps 加虚拟背景。这个策略的实质是把过去放在服务端 Year Class 体系里的判断，原原本本还给了浏览器。过去 mobile Gmail、Facebook 都在服务端维护了一套设备能力到 HTML/JS bundle 的映射，现在浏览器提供了一个标准化的替代方案。

但这里也有两个要注意的边界。第一，这个 API 只解决静态能力判断，不解决实时负载。CPU tier 高不代表当前 CPU 有空，所以 spec 明确建议搭配 Compute Pressure API 动态监控压力。第二，隐私和 fingerprinting 的讨论没有停止。Zyte 的分析指出，Chrome 内部分类逻辑已经公开进 spec，结合 core count 和少量 CPU family 的 promotion/demotion table，特定 band 下的 tier 值实际上会泄露 CPU 家族信息；Mozilla 和 WebKit 对此也仍有顾虑。所以生产环境里不要把 tier 和用户 ID、设备 ID 绑定存储，也不要跨站共享。

对你现有项目的落地，最直接的一步是把视频、WebGPU、 heavy JS bundle 的加载策略和 navigator.cpuPerformance 挂钩。Web 端能原生判断设备算力，这件事在 2026 年 8 月之前并不存在。过去你只能靠猜测；现在浏览器主动给了你一个可用的、可覆写的、隐私受限的信号。先用它做静态分级，再拿 Compute Pressure API 做动态兜底，这可能是近期最值得花半小时改完的性能优化。