CPU パフォーマンス API

1. はじめに

この節は非規範的です。

ユーザーのデバイスがどの程度高性能であるかにもとづいて Web コンテンツを適応させることには、常に開発者の関心がありました。 たとえば、ビデオ会議アプリケーションやビデオゲームは、 高度なビデオ効果をレンダリングできるかどうかを判断するために この情報を使用することがあります。また、あらゆる種類のアプリケーションが、 AI タスクをローカルで実行しようとするか、サーバーに委任するかなどを 判断するためにこの情報を使用することがあります。

特に、Web アプリケーションはパフォーマンス情報を次の目的で使用したい場合があります:

1. 必須ではないタスクやリクエストを制御する。たとえば、 3rd party スクリプトを許可またはブロックする、 重いライブラリを使用するか避けるかを決定する。

2. Web コンテンツの複雑さを調整する。たとえば、 画像や動画の解像度と形式、 データをアップロードする際の圧縮レベル、 アニメーションなどの計算負荷の高い処理を有効または無効にすること、 リソース管理（遅延読み込み、プリフェッチ、プリレンダリング）を改善すること。

3. 実ユーザー監視を改善する。たとえば、 ユーザーがより高速なデバイスまたはより低速なデバイスを持っているかを よりよく理解し、 開発の労力をより適切に集中させる。

4. 計算をクライアント側で実行するかサーバー側で実行するかを決定する。たとえば、 サーバーサイドレンダリングを使用する、 AI アプリケーションや LLM をクライアント側で実行する。

5. ユーザーのデバイスにより適した広告を選択する。

2. CPU パフォーマンス

現代のコンピューティングデバイスは、多くの場合、性質や能力の異なる 複数の異種 処理ユニットを統合しています。 中央処理装置（CPU）は、あらゆる コンピューティングデバイスの中核的な構成要素です。 現代のコンピューティングデバイスには、複数の集積回路（マルチコア プロセッサ）が含まれ、それぞれに独立した CPU として動作する複数の 物理 コアが含まれます。 さらに、同時マルチスレッディング（またはハイパースレッディング）の技術により、 物理コアは 複数の命令スレッドを処理できるため、 オペレーティングシステムには複数の別個の 論理コアとして 見えます。

CPU 以外にも、現代のコンピューターには次のような他の種類の処理ユニットが 含まれることがあります:

• 複雑なグラフィックス、動画、 および科学シミュレーションや AI トレーニングのような計算負荷の高いタスクを 並列で処理するためのグラフィックス処理装置（GPU）;

• AI や機械学習タスクのパフォーマンスを向上させるための ニューラル処理装置（NPU）または Tensor Processing Unit（TPU）;

• 信号のリアルタイム処理を最適化するための デジタル信号プロセッサ（DSP）;

• 再構成可能でプログラム可能なハードウェアによって実装される カスタムアクセラレータを通じて特定のタスクを最適化するための Field-Programmable Gate Array（FPGA）など。

この仕様は現在、中央処理装置のみを扱い、 そのパフォーマンスの尺度を Web アプリケーションに公開することを目的としています。 この仕様の将来のバージョンでは、他の種類の 処理ユニットも扱う可能性があります。

コンピューティングデバイスに含まれる中央処理装置の集合を指すために、 CPUという 用語を使用します。 命令スレッドを実行できる CPU の一部を 指すために、 オペレーティングシステムが報告する 物理 または論理の コアという 用語を使用します。 CPU のクロック速度を指すために、 周波数という用語を使用します。これは 1 秒あたりのサイクル数（Hz）で表され、 物理コアが命令を実行できる速さを決定します。

Web アプリケーションの観点から、 CPU がどの程度高速であると認識されるかを指すために、 パフォーマンスという用語を使用します。 高速な CPU はタスクをより迅速に処理します。たとえば、 アプリケーションの読み込みが速くなり、マルチタスクが向上し、 ゲームがより滑らかになる、などです。

3. パフォーマンス階層

CPU Performance API は、ユーザーデバイスを、その CPU の パフォーマンスに応じて、少数の パフォーマンス 階層に分類します。各パフォーマンス階層は、小さな正の 整数で表されます。値が大きいほど、より高いパフォーマンス階層に対応します。すなわち、 より高性能なユーザーデバイスに対応します。

4 つの異なるパフォーマンス階層があり、1–4 の番号が付けられます。 この API を使用するアプリケーションは、デバイスが時間とともに向上するにつれて将来追加される可能性が高い、 追加の階層（5 以上の番号）を処理するべきです。

特別な値 0（ゼロ）は、不明なパフォーマンス階層に対応し、 API の実装がユーザーデバイスを分類できない場合に返されます。

3.1. パフォーマンス階層値の算出

ユーザーデバイスのパフォーマンス階層への分類は 実装定義であり、Web アプリケーションは それぞれの具体的な必要に応じて解釈するべきです。ただし、この API の実装は 次の規則に従うべきです:

1. 一貫性: デバイスのパフォーマンス階層への対応付けは、 特定のベンチマークで測定できる CPU の パフォーマンスを反映するべきです。 理想的には、ブラウザーが提供するプログラミングツール （JavaScript、WebAssembly など）を使用し、理想的な条件で測定されるものです。 より高性能なデバイスは、より低性能なデバイスよりも低いパフォーマンス階層に 分類されるべきではありません。

2. 再現性: 実装は、同じユーザーデバイスについて常に同じ パフォーマンス階層を 報告するべきです。特に:

   • 報告されるパフォーマンス階層は、ユーザー デバイスの 現在の負荷や使用率に依存するべきではありません; かつ

   • 実装は階層を再定義するべきではありません。つまり、 技術の進歩に伴い、より新しく高性能なデバイスに対応するために、 tier 4 のデバイスを tier 3 として再分類するべきではありません。 代わりに、そのような新しいデバイスについては、必要が生じたときに 新しいtier 5 がこの仕様に追加され、その後 tier 6 というように 追加されます。

   注: この規則の意図は、 この API の実装における分類ミスの修正を 不可能にすることではありません。そのようなミスは 必然的に修正される必要があります。むしろ、この規則の意図は、 新しい技術が登場しても CPU モデルを再分類しないことであり、 旧式のアプリケーションを実行している旧式のマシンの挙動を 壊さないようにするためです。

3. ユーザーのプライバシー: ユーザーのフィンガープリンティングを避けるため、 実装は各パフォーマンス階層に 十分に多数のユーザーデバイスを分類するべきです （§ 5 セキュリティとプライバシーに関する考慮事項も参照）。 特に、何らかの CPU モデルデータベースにもとづく実装は、 データベースに含まれていない新しいユーザーデバイスについて、特別な値 0 を 返すべきではありません。この特別な 値は、実装がオペレーティングシステムから CPU に関する情報を取得できない場合にのみ 返されるべきです。

実装は、次の特性にもとづいて、特定のユーザーデバイスのパフォーマンス階層 値を計算してもよい（ただし必須ではありません）:

• CPU モデル;

• コアの数、すなわち 物理および/または論理コア;

• 周波数; および

• その他の利用可能な CPU 特性。

4. Javascript API

[
    SecureContext,
    Exposed=Window
] partial interface Navigator {
    readonly attribute unsigned short cpuPerformance;
};

5. セキュリティとプライバシーに関する考慮事項

CPU Performance API は HTTPS セキュアコンテキストでのみ利用可能になります。

フィンガープリンティングのリスクを低減するため、CPU Performance API は CPU 特性を直接明らかにしません。報告される値は小さな整数であり、 CPU に対応する パフォーマンス 階層を表します。各可能な値（tier）について、 実装は、任意の時点でインターネット上に存在するコンピューティングデバイスの 十分に大きな数が、絶対数としても異なる CPU モデルとしても、 このパフォーマンス 階層を持つものとして分類されることを保証するべきです。特に、この 仕様の意図は、各パフォーマンス階層が、任意の時点で存在する CPU モデルの 10% 以上、 および既存のユーザー デバイスの 10% 以上を含むべきである、というものです。

TAG セキュリティ/プライバシー質問票も参照してください。

6. 例

この節は非規範的です。

ビデオ会議アプリケーションは、4 つのパフォーマンス階層を 次のように解釈できます。この解釈はアプリケーション固有であり、その場合でも、 アプリケーション自体が更新され、ハードウェア要件が変化した場合には、 将来更新する必要があるかもしれません。

• 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, and Chen Xing.

W3C Web Performance Working Group（WebPerf）、特に Yoav Weiss に感謝します。