1. 引言
本节为非规范性内容。
开发者一直有兴趣根据用户设备的性能强弱来调整 Web 内容。 例如，视频会议应用或视频游戏可能会使用这些信息来决定是否可以渲染 高级视频效果；各种类型的应用也可能会使用这些信息来决定是否 尝试在本地运行 AI 任务，或委托给服务器等。
具体而言，Web 应用可能希望使用性能信息来：
-
控制非必要任务和请求；例如， 允许或阻止第三方脚本， 使用或避免使用大型库。
-
调整 Web 内容的复杂度；例如， 图像和视频的分辨率与格式， 上传数据的压缩级别， 启用或禁用动画等计算量较大的操作， 改进资源管理（延迟加载、预取、预渲染）。
-
改进真实用户监测；例如， 更好地了解用户拥有更快还是更慢的设备， 更恰当地集中开发工作。
-
在客户端侧运行计算，而不是在服务器侧运行；例如， 使用服务器端渲染， 在客户端侧运行 AI 应用和 LLM。
-
选择更适合用户设备的广告。
2. CPU 性能
现代计算设备通常集成多个异构 处理单元，它们在性质和能力上各不相同。 中央处理单元（CPU）是每个计算设备中的核心组件。 现代计算设备包含若干集成电路（多核 处理器），每个集成电路包含若干个作为独立 CPU 运行的 物理 核心。 此外，同步多线程（或超线程）技术 允许 物理核心 处理 多个指令线程，因此在 操作系统看来表现为多个独立的 逻辑核心。
除 CPU 之外，现代计算机还可能包含其他类型的处理单元， 例如：
-
图形处理单元（GPU），用于并行处理复杂图形、视频 以及计算密集型任务，例如科学仿真 和 AI 训练；
-
神经处理单元（NPU）或张量处理单元（TPU），用于提升 AI 和机器学习任务的性能；
-
数字信号处理器（DSP），用于优化信号的实时处理；
-
现场可编程门阵列（FPGA），用于通过 可重配置、可编程硬件实现的自定义加速器 优化特定任务，等等。
本规范目前仅涉及中央处理单元， 旨在向 Web 应用公开其性能的一个度量。 本规范的未来版本也可能涉及其他类型的 处理单元。
我们将使用术语 CPU 来指代 计算设备中包含的一组中央处理 单元。 我们将使用术语 核心 来 指代可执行指令线程的 CPU 部分，即操作系统报告的 物理 或 逻辑 核心。我们将使用术语 频率 来指代 CPU 的时钟速度，以每秒周期数（Hz） 表示，并决定 物理核心 执行指令的速度。
我们将使用术语 性能 来指代从 Web 应用的角度看， CPU 被感知到的速度。快速的 CPU 可以更快地处理任务，例如带来更快的应用加载、更好的 多任务处理、更流畅的游戏体验等。
3. 性能等级
CPU Performance API 根据用户设备的 CPU 性能，将其归类到少数几个 性能 等级。每个 性能等级 由一个较小的正 整数表示。值越高，对应的 性能等级 越高，即 用户设备越强大。
共有四个不同的 性能等级，编号为 1–4。使用 该 API 的应用应处理额外的 等级（编号为 5 及 以上），随着设备随时间改进，这些等级很可能会在未来添加。
特殊值 0（零）对应未知的 性能等级， 当该 API 的实现无法对用户设备进行分类时返回。
3.1. 计算性能等级值
将用户设备分类到 性能等级 是 由实现定义的，并且应由 Web 应用 根据其特定需求进行解释。不过，该 API 的实现应 遵循以下规则：
-
一致性：设备到 性能等级 的映射应 反映可通过特定基准测试测量到的 CPU 性能，理想情况下使用浏览器提供的编程工具 （JavaScript、WebAssembly 等）并在理想条件下测量。性能更强的 设备不应被归类到比性能较弱设备更低的 性能等级 中。
-
可复现性：实现应始终为同一用户设备报告相同的 性能等级。 具体而言：
-
报告的 性能等级 不应取决于用户 设备的 当前负载或利用率；并且
-
实现不应重新定义 等级；也 就是说，随着技术进步，不应为了容纳更新、更高性能的设备 而将 等级 4 设备重新分类为 等级 3。 相反，当有需要时，本规范会为这些更新的设备添加新的 等级 5， 然后再添加 等级 6，依此类推。
注： 此规则的目的并不是让 修复该 API 实现中的分类错误变得不可能。这类错误 不可避免地需要被修复。相反，该规则的目的 是不要因为新技术出现而重新分类 CPU 型号，以免 破坏运行过时应用的过时机器的行为。
-
-
用户隐私：为避免用户指纹识别，实现应 在每个 性能等级 中分类数量相当多的用户设备（另见 § 5 安全与隐私考量）。 具体而言，基于某些 CPU 型号数据库的实现，不应 对数据库中未包含的新用户设备返回特殊值 0。该特殊 值仅应在实现无法从操作系统获取有关 CPU 的信息时返回。
实现可以（但不要求）根据以下特征计算给定用户设备的 性能等级 值：
4. JavaScript API
[
SecureContext ,
Exposed =Window
] partial interface Navigator {
readonly attribute unsigned short cpuPerformance ;
};
cpuPerformance getter
步骤为：
-
令 tier 为一个
unsigned short， 表示设备 CPU 的 性能等级，它以 由实现定义的方式生成，同时考虑 § 3.1 计算 性能等级值 中描述的建议 和约束。 -
断言：0 ≤ tier ≤ 4。
-
返回 tier。
5. 安全与隐私考量
CPU Performance API 仅可用于 HTTPS 安全上下文。
为降低指纹识别风险，CPU Performance API 不会直接公开 CPU 特征。报告的值是一个较小的整数， 表示与 CPU 对应的 性能 等级。对于每个 可能的值（等级）， 实现应确保互联网上在任意给定 时间存在的相当多计算设备，无论按绝对数量还是按不同的 CPU 型号计算，都被分类 为具有该 性能 等级。具体而言，本 规范的意图是，每个 性能等级 应包含不少于现有 CPU 型号的 10%，且不少于任意给定时间现有用户 设备的 10%。
另见 TAG 安全/隐私调查问卷。
6. 示例
本节为非规范性内容。
视频会议应用可以按如下方式解释这四个 性能等级。 这种解释是应用特定的，即便如此，如果应用本身未来更新并且其 硬件需求发生变化，它也可能 需要随之更新。
-
1：几乎无法用于视频通话的设备；
-
2：性能不足但仍然基本适合视频通话的设备；
-
3：可以轻松支持视频通话的设备；以及
-
4：可以运行甚至最严苛场景，并且还有 余量进行多任务处理的设备。
这样的应用可以使用 navigator.cpuPerformance 的值
来预先选择若干最适合用户设备
性能
等级 支持的功能。
function getPresetFeatures() { switch ( navigator. cpuPerformance) { case 1 : return { videoQuality: "QVGA" , frameRate: 15 , effects: [], }; case 2 : return { videoQuality: "VGA" , frameRate: 15 , effects: [ 'voice-detection' , 'animated-reactions' ], }; case 3 : return { videoQuality: "720p" , frameRate: 30 , effects: [ 'voice-detection' , 'animated-reactions' , 'noise-reduction' ], }; case 4 : case 0 : // 对未知设备假设使用高性能设置 default : // 以及对高于 4 的性能等级同样如此。 return { videoQuality: "1080p" , frameRate: 30 , effects: [ 'voice-detection' , 'animated-reactions' , 'noise-reduction' , 'virtual-background' ], }; } }
7. 致谢
非常感谢以下人士提供的宝贵反馈和建议： Dominic Farolino、 Deepti Gandluri、 Reilly Grant、 Tomas Gunnarsson、 Markus Handell、 Michael Lippautz、 Thomas Nattestad、 Nicola Tommasi、 Guido Urdaneta、 Måns Vestin 和 Chen Xing。
感谢 W3C Web Performance Working Group（WebPerf），尤其是 Yoav Weiss。