ScreenTest.Proスコアの仕組み

ここは方法論のページです。マーケティングのために簡略化したところはありません。コードとこのページが食い違っていたら、それはバグなので、ぜひお知らせください。（執筆時点のベンチマークバージョン：2.2.0）

このベンチマークで測るもの

多くのグラフィックスベンチマークは負荷を固定してフレームレートを測ります。本テストは逆に、目標フレーム時間を固定し、端末がその時間内で維持できる最も重い負荷を探します。各シーンの「最大安定負荷」、たとえば星雲粒子840,000個を取得し、そこからスコアを作ります。

この方式にしたのは、ブラウザのフレームレートが画面の更新レートで頭打ちになりやすいためです。固定した軽い負荷だけでは、速い端末にどれほど余裕があるか分かりません。処理できる負荷を探すことで、5年前のスマートフォンからデスクトップGPUまで、同じシーンと判定基準で比較できます。

実行内容

標準プロファイルは5つのシグネチャーシーンと1つの対照からなり、それぞれ異なる要素へ負荷をかけます。

描画はピクセル比を1.5×に制限し、内部サイズにも上限を設けます。5Kモニターと1080pノートPCが同程度のピクセル数を処理するためです。乱数にはシードを使い、シミュレーションの時間刻みも固定しているので、同一バージョンは毎回同じ処理を行います。

安定性の判定

エンジンは FPS カウンターを読みません。ブラウザのアニメーションクロックからフレーム時間を約 0.7〜1.6 秒のウィンドウに集め、各ウィンドウに2つのことを求めます。

• 合格しきい値を超えるフレームは 5% 以下であること——可変リフレッシュのディスプレイでは 17.5 ms、固定リフレッシュのディスプレイでは、予算内の処理が決して収まりえない最初の垂直同期スロット（60 Hz なら 25.0 ms、120 Hz なら 20.8 ms）;
• トリム平均——最悪の 2% のフレームを除外——が 16.67 ms × 1.15 の範囲に収まること。

超過を平均せずに数えることで、ガベージコレクションの一時停止は「不合格のウィンドウ」ではなく「1枚の悪いフレーム」で済みます。トリム平均はその裏取りで、まれに起きる巨大な超過が枚数だけで通り抜けるのを防ぎます。

しきい値がディスプレイを気にする理由：固定 60 Hz のモニターは 16.7 ms か 33.3 ms でしかフレームを表示できず、その中間はありません。一方、可変リフレッシュのノート用パネルは 18 ms のフレームを 18 ms のまま返します。2.1.0 の平均・P95 の許容値では、この違いのせいで可変パネルは 55 fps のまま合格でき、60 Hz のモニターは本物の 60 を保たねばなりませんでした。同じ GPU でも、机の上ではノートのふたの中より低く出たのです。そこで最初のシーンの前に、約 600 ms のペーシング測定がディスプレイのフレームの返し方を観察し、「60 fps を維持する」がどのディスプレイ区分でも同じ主張になるよう基準が調整されます。測定でディスプレイが約 50 Hz 未満に制限されていると分かった場合——低電力モード、30 Hz のケーブル——測定は開始を拒みます。30 Hz のストロー越しに GPU を採点することはしません。

16.67 ms という予算そのものは、リフレッシュレートによって変わりません。120 Hz の画面は余裕があるとき 8.3 ms 間隔でフレームを届けますが、合格に必要なのは毎秒 60 枚の予算に収まることだけです。高リフレッシュのハードウェアは対等に測られ、余分なフレームを見せたことで罰せられることはありません。

探索手順

各シーンは状態機械をたどります：preflight → baseline → warmup → ramp → bracket → confirm → anchor。

1. Baseline は既知の軽い負荷を測ります。これが熱の基準になります。
2. Ramp は合格したウィンドウごとに負荷を約 1.5× し、いずれかのウィンドウが不合格になるまで続けます。
3. Bracket は最後に合格した負荷と最初に不合格になった負荷のあいだを二分探索し、範囲が約 6% まで狭まるまで詰めます。
4. Confirm は候補の負荷で3回連続の合格ウィンドウを、4回の予算内で要求します。序盤の1回の失敗なら取り返せますが、2回連続の失敗、または3連続が出ないまま予算を使い切った場合は、その段階を却下して候補を1段下げます。
5. Anchor は基準負荷をもう一度走らせます。開始時より 15% 以上遅くなっていれば、測定中に端末のほうが変わったということで——ほぼ必ずサーマルスロットリングです——何事もなかったふりをせずに、そのシーンをドリフトとして印を付けます。遅くなった度合いも、事実だけでなく記録します。

負荷を変えた直後の数フレームは、統計を再開する前に破棄します。負荷の変更は GPU バッファとレンダーターゲットを確保し直し、ブラウザはそれを1枚の非常に長いフレームとして計上するからです。そのつまずきは遷移に属するものであってワークロードではありません。2.1.0 はこれを数えており、段ごとにレンダーターゲットの大きさを変えるシーンでは、ハードウェアが実際に維持できる水準よりはるかに下で探索を止めていました。

どの段階にも厳密な時間制限があります（1シーン 30 秒、1回の測定 200 秒）。タブを背面に回すと測定は一時停止し、進行中のウィンドウは無効になります。サイズ変更はシーンを作り直し、ウォームアップからやり直します。状態機械の中に、止まったままになる経路はありません。

負荷からスコアへ

採点は記録された結果に対する純粋な関数です。手で計算し直すこともできます。

1. 各シーンの最大安定負荷を、そのシーンの参照負荷（バージョンごとに凍結された較正定数。おおよそ、2025 年の堅実なデスクトップが 1.0 前後になります）で割ります。
2. 比は下限を 0.05 とし、上限はそのシーン自身のはしごの天井——そのシーンが物理的に組み立てられる最も重い負荷で、これまでに測定した最速のハードウェアのおよそ 10 倍先に置かれています——で頭打ちにします。こうすることで、スコアは測定そのものが終わる場所でしか止まらなくなります。（2.1.0 はすべてのシーンを一律 20× で抑えていました。M4 Max は2つのシーンをそこに、3つ目を測定の天井に押し付けており、無関係なはずのアップルのフラッグシップが近い総合値を報告し続けたのはそのためです。）
3. 抑えた比を加重幾何平均にまとめます。5つの Signature シーンが重みの大半を担い、Canvas 2D の対照は 10% です。幾何平均なのは、それが均衡を評価するからです。何でもこなせる機械が、1つだけ伝説的でほかが悲惨な機械に勝ちます。
4. 1000 を掛け、安定性の減点——印の付いたシーン1つにつき 3%、印がドリフトでも未確認の段階でも同じ、合計で最大 10%——を適用し、丸めます。

ティアはバージョンごとの固定しきい値です。スコアは参照機の 1000 倍なので、各ティアは実質その倍数です。エントリーは 1000 未満、バランスは 2999 まで、ファストは 8999 まで、エクストリームはその上——つまり 1× 未満、3× まで、9× まで、そしてその先です。数値に取っ手を付けるためのもので、本当の情報はシーンごとのスコアのほうです。

比較を無効にする条件

• 異なるベンチマークバージョンは決して比較できません。 シェーダーを1つ変えればワークロードが変わります。結果シートのバージョン文字列はスコアの一部です。
• 互換モードの測定（WebGL2 なし）は Classic シーンだけを使い、独自の空間で採点され、はっきり表示されます。
• スロットリングした測定——全シーンを測定して確認できたが、端末が温まって遅くなった場合——は持続性能の本物の測定なので、通常どおり採点され、行に印を付けたまま上位スコアのランキングに並びます。スマートフォンの測定はほとんどここに入ります。それは物理であって、不具合ではありません。
• デグレードした測定——使える結果を出せなかったシーン、または探索が最後まで確認できなかった段階——はピークではなく下限なので、ランキングには入りません。それでも保存され、集計の中央値には引き続き数えられ、結果シートがどのシーンでなぜかを伝えます。
• どちらの印も測定と一緒に匿名データセットへ入るので、公開されるどの数値もそれらを分けて扱えます。

実行間のばらつきと目安

電源につないだ、何もしていない機械では、続けて実行した測定はたいてい数パーセント以内に収まります。それを買っているのが、確認フェーズの「連続したウィンドウ」という要求です。バッテリー駆動、省電力モード、あるいは筐体が温まっている状態では、ばらつきは大きくなり、スロットリングの印が付く可能性も高くなります。ベンチマークの気分屋なところではなく、端末が本当にそれだけしか出せていないということです。実行前に冷まして電源につなぐことが、代表的な数値を得るために最も効く一手です。ブラウザのベンチマークで測れること・測れないことでは、得られた数値をどう扱うかを説明しています。