停止しないブラウザベンチマークを作る
ベンチマークが97%で止まる、実行するたびに点数が30%も変わる、高リフレッシュレートのノートPCなのに低い点数になる。2.0の開発では、こうした問題を一つずつ整理して対策しました。この記事では、その設計を紹介します。
FPSではなく、安定して描ける負荷を探す
固定した負荷でFPSを測る方法は一般的ですが、ブラウザでは画面の更新に制約されます。処理に余裕がある端末でも、表示が60 Hzなら約60 fps、120 Hzなら約120 fpsで頭打ちになりやすく、余裕の違いを見分けられません。一方、負荷が重すぎる端末では動きが極端に遅くなります。
そこで、目標となるフレーム時間を16.67 msに固定し、描画する負荷を変える方式にしました。粒子数などを増やして基準を超える水準を探し、その前後を二分探索で絞り込みます。最後に3回連続の確認を通過した負荷を採用します。たとえば星雲の粒子840,000個という結果なら、その条件で安定性の基準を満たした描画負荷を表します。
この方式なら、処理能力が低い端末でも軽い負荷まで下げて測定できます。速い端末と遅い端末を、同じフレーム時間の基準で評価できます。
カクつきは平均値に隠れるため、パーセンタイルを使う
各測定区間では、平均フレーム時間と95パーセンタイル（p95）の両方を確認します。大半のフレームが速くても、一部に40 msほどの遅いフレームが混ざると、動きの不均一さを感じることがあります。平均とp95を併用するのは、そうした傾向を捉えるためです。通知やガベージコレクションなどによる単発の乱れでは測り直し、連続して基準を外れる場合はその負荷を不合格にします。
途中で止まらないための終了処理
測定が途中で進まなくなる状況に備え、各シーンをpreflight、baseline、warmup、ramp、bracket、confirm、anchorの状態に分けました。それぞれに時間上限と終了処理を設けています。
- 2.0開発時点では1シーン30秒、全体150秒の時間上限を設けました。
- タブをバックグラウンドへ移すと現在の測定ウィンドウを無効にして一時停止し、30秒以上隠れた場合は理由を示して終了します。
- サイズ変更やピクセル比の変化があれば、無効な値を測るのではなく、シーンを再構築してウォームアップし直します。
- WebGLコンテキストの消失、数秒間フレームが来ないGPU停止、シーンの例外にはそれぞれ固有の終了理由があります。描画ループとは別のタイマーでも停滞を監視します。
- 各状態でEscによるキャンセルを受け付けます。
状況に応じて早期終了やキャンセルとし、理由を表示できるようにしています。ただし、OSやブラウザのプロセス自体が停止した場合まで、ページ内の処理で復帰を保証することはできません。
実行中の性能変動を記録する
GPUに負荷をかけ続けると端末の温度が上がり、性能が変わることがあります。そのため、各シーンの前後で軽い基準負荷を測定します。終了時のフレーム時間が15%以上長くなっていれば、性能変動として記録します。この状態は結果表に表示され、上限付きの減点にも反映されます。サンプルを送信した場合も状態を保持し、公開中央値の集計で条件をそろえられるようにしています。温度そのものを測っているわけではないため、原因を熱だけに断定はしません。
高リフレッシュレートへの公平性
画面の更新間隔をそのまま合否基準にすると、120 Hzの端末は約8.3 ms、60 Hzの端末は約16.67 ms以内で描画する必要があり、条件が変わってしまいます。このベンチマークでは、全端末に共通の16.67 msを基準にしています。高リフレッシュレート画面の滑らかさと、一定の条件で処理できる描画負荷を分けて評価するためです。
意図的に除外したもの
この版ではWebGPUを採用していません。追加する場合は、既存のスコアに混ぜず、別のプロファイルとして扱う方針です。描画用Web Workerも、停止処理やコンテキストの受け渡しが複雑になるため採用していません。また、匿名データのサンプル数が十分でない段階では、全体の上位何%という順位を表示しません。40回ほどの実行だけでは、端末全体を代表する分布とは言えないためです。
採点式と現在の仕様は測定方法で公開しています。この記事は2.0開発時点の記録で、その後に探索範囲や全体の時間上限を変更しています。測定が進まない端末があれば、ブラウザ名や再現条件を添えてadmin at screentest.proへお知らせください。