1. はじめに
この節は非規範的です。
ユーザーのデバイスがどの程度高性能であるかにもとづいて Web コンテンツを適応させることには、常に開発者の関心がありました。 たとえば、ビデオ会議アプリケーションやビデオゲームは、 高度なビデオ効果をレンダリングできるかどうかを判断するために この情報を使用することがあります。また、あらゆる種類のアプリケーションが、 AI タスクをローカルで実行しようとするか、サーバーに委任するかなどを 判断するためにこの情報を使用することがあります。
特に、Web アプリケーションはパフォーマンス情報を次の目的で使用したい場合があります:
-
必須ではないタスクやリクエストを制御する。たとえば、 3rd party スクリプトを許可またはブロックする、 重いライブラリを使用するか避けるかを決定する。
-
Web コンテンツの複雑さを調整する。たとえば、 画像や動画の解像度と形式、 データをアップロードする際の圧縮レベル、 アニメーションなどの計算負荷の高い処理を有効または無効にすること、 リソース管理（遅延読み込み、プリフェッチ、プリレンダリング）を改善すること。
-
実ユーザー監視を改善する。たとえば、 ユーザーがより高速なデバイスまたはより低速なデバイスを持っているかを よりよく理解し、 開発の労力をより適切に集中させる。
-
計算をクライアント側で実行するかサーバー側で実行するかを決定する。たとえば、 サーバーサイドレンダリングを使用する、 AI アプリケーションや LLM をクライアント側で実行する。
-
ユーザーのデバイスにより適した広告を選択する。
2. CPU パフォーマンス
現代のコンピューティングデバイスは、多くの場合、性質や能力の異なる 複数の異種 処理ユニットを統合しています。 中央処理装置（CPU）は、あらゆる コンピューティングデバイスの中核的な構成要素です。 現代のコンピューティングデバイスには、複数の集積回路（マルチコア プロセッサ）が含まれ、それぞれに独立した CPU として動作する複数の 物理 コアが含まれます。 さらに、同時マルチスレッディング（またはハイパースレッディング）の技術により、 物理コアは 複数の命令スレッドを処理できるため、 オペレーティングシステムには複数の別個の 論理コアとして 見えます。
CPU 以外にも、現代のコンピューターには次のような他の種類の処理ユニットが 含まれることがあります:
-
複雑なグラフィックス、動画、 および科学シミュレーションや AI トレーニングのような計算負荷の高いタスクを 並列で処理するためのグラフィックス処理装置（GPU）;
-
AI や機械学習タスクのパフォーマンスを向上させるための ニューラル処理装置（NPU）または Tensor Processing Unit（TPU）;
-
信号のリアルタイム処理を最適化するための デジタル信号プロセッサ（DSP）;
-
再構成可能でプログラム可能なハードウェアによって実装される カスタムアクセラレータを通じて特定のタスクを最適化するための Field-Programmable Gate Array（FPGA）など。
この仕様は現在、中央処理装置のみを対象としており、 その性能の尺度を Web アプリケーションに公開することを目的としている。 この仕様の将来のバージョンでは、他の種類の 処理装置も対象となる可能性がある。
コンピューティングデバイスに含まれる中央処理装置の 集合を指す用語として CPU を使用する。 命令スレッドを実行できる CPU の一部を 指す用語として コア を使用する。これは、オペレーティングシステムによって報告される 物理 または 論理のコアである。
Web アプリケーションの観点から見て、CPU がどの程度高速であると 認識されるかを指す用語として 性能 を使用する。高速な CPU はタスクをより迅速に処理し、たとえば、アプリケーションの読み込みの高速化、より優れた マルチタスク処理、より滑らかなゲームプレイなどにつながる。
3. パフォーマンス階層
CPU Performance API は、ユーザーデバイスを、その CPU の パフォーマンスに応じて、少数の パフォーマンス 階層に分類します。各パフォーマンス階層は、小さな正の 整数で表されます。値が大きいほど、より高いパフォーマンス階層に対応します。すなわち、 より高性能なユーザーデバイスに対応します。
4 つの異なるパフォーマンス階層があり、1–4 の番号が付けられます。 この API を使用するアプリケーションは、デバイスが時間とともに向上するにつれて将来追加される可能性が高い、 追加の階層（5 以上の番号）を処理するべきです。
特別な値 0（ゼロ）は、不明なパフォーマンス階層に対応し、 API の実装がユーザーデバイスを分類できない場合に返されます。
3.1. パフォーマンス階層値の算出
注: 実装は、CPU モデルが、その コア数として一般的な性能よりも大幅に高い、または 低い性能を示すことが分かっている場合、返される 性能 ティアを調整してもよい。このような調整では通常、 性能 ティアを 1 つのティアレベルを超えて変更することはなく（すなわち、 +1 または −1）、オペレーティングシステムから CPU モデルに関する 信頼できる情報を取得できることが必要である。このような 調整を適用する CPU モデルの集合は 実装定義である。
注: このアルゴリズムの JavaScript リファレンス 実装は、 Chromium ブラウザーエンジンの実装から導出された代表的なモデルベースの調整一式を含め、 cpu-performance リポジトリで利用できる。 また、アルゴリズムとそのモデルベースのヒューリスティックが、さまざまな 実世界のデバイスをどのように分類するかを示す インタラクティブなデモ ページも用意されている。これらは規範的なものではなく、モデルベースの調整を 適用した、この節のアルゴリズムの推奨実装を 示すものである。
この API の実装は、次の規則にも従うべきである。
-
一貫性: 性能ティアに対するモデルベースの調整は、 特定のベンチマークで測定できる CPU の 性能を反映すべきであり、 理想的にはブラウザーが提供するプログラミングツール （JavaScript、WebAssembly など）を使用し、理想的な条件下で測定する。より 高性能なデバイスを、より低性能なデバイスよりも低い 性能ティアに 分類すべきではない。
-
再現性: 実装は、同じユーザーデバイスに対して常に同じ 性能ティア を報告すべきである。特に、次のとおりである。
-
報告される 性能ティアは、ユーザー デバイスの現在の負荷または使用率に依存すべきではない。また、
-
実装は ティアを再定義すべきではない。すなわち、 技術の進歩に伴って、より新しく高性能なデバイスに対応するために、ティア 4 のデバイスを ティア 3 に再分類すべきではない。代わりに、必要が 生じた時点で、それらの新しいデバイス向けに新たな ティア 5 がこの仕様に追加され、その後は ティア 6 というように追加される。
注: この規則の意図は、この API の実装における 分類の誤りを修正できなくすることではない。そのような誤りは 必然的に修正する必要がある。むしろ、この規則の意図は、 新しい技術の登場に伴って CPU モデルを再分類しないことであり、 古いアプリケーションを実行する旧式のマシンの動作を壊さないようにすることである。
-
-
ユーザーのプライバシー: ユーザーのフィンガープリンティングを避けるため、実装は、 各 性能 ティアに十分に多数のユーザーデバイスが含まれるように すべきである（§ 5 セキュリティおよびプライバシーに関する考慮事項も参照）。特に、 モデルベースの調整は、各 性能ティアに引き続き 多数の異なる CPU モデルが含まれる程度に粗くすべきであり、特殊な 値 0 は、実装がオペレーティングシステムから コア数に関する情報を取得できない場合にのみ 返すべきである。
4. Javascript API
[
SecureContext ,
Exposed =Window
] partial interface Navigator {
readonly attribute unsigned short cpuPerformance ;
};
cpuPerformance getter の
手順は次のとおりである。
-
tier を、デバイスの CPU の 性能 ティアを算出した結果とし、必要に応じて § 3.1 性能ティア値の算出で説明されている モデルベースの調整を適用する。
-
表明: 0 ≤ tier ≤ 4。
-
tier を返す。
5. セキュリティとプライバシーに関する考慮事項
CPU Performance API は、HTTPS セキュアコンテキストでのみ利用可能となる。
フィンガープリンティングのリスクを軽減するため、CPU Performance API は CPU の特性を直接公開しない。報告される値は、 性能 ティアを表す小さな整数値であり、これは CPU に対応する。各 可能な値（ティア）について、 実装は、任意の時点でインターネット上に存在する 十分に多数のコンピューティングデバイスが、絶対数としても、異なる CPU モデル数としても、この 性能 ティアを持つものとして分類されるようにすべきである。特に、この 仕様の意図は、各 性能ティアに、既存の CPU モデルの 10% 以上、かつ任意の時点で既存のユーザー デバイスの 10% 以上が含まれるようにすることである。
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 に感謝します。