フレームレートテスト

フレームレートテストは、デバイスが1秒間に何枚の画像を表示し、それらがどれだけ均等に届いているかを測定します。このテストはブラウザがすべてのアニメーションフレームに付与するタイムスタンプをサンプリングし、連続するフレーム間の間隔をFPSのフレームレートに換算します。そこから6つの数値を報告します。ライブカウンター、平均、最小、1% Low、フレーム間隔の標準偏差、スタッター数です。平均は処理能力を表し、残りの5つは安定性を表すため、別々に報告されます。1つの平均値だけでは、その計測が滑らかだったのか、引っかかりだらけだったのかはわかりません。

このタブがアクティブウィンドウであることを確認してください。ブラウザはバックグラウンドタブのアニメーションフレームを間引くため、計測値がごく低い値に落ち込んでしまいます。重いアプリを閉じ、「テスト開始」をクリックして少なくとも10秒間カウンターを動かしてください。10秒で計測が自動的に完了し、診断パネルが採点します。まず平均が安定するのを見て、そのすぐ下の1% Lowと比較し、最後にフレームタイムのジッターとスタッター数を読みます。公平な比較のために、同じ条件で3回計測し、1回の値ではなくばらつきを比べてください。1回の計測はバックグラウンドの更新だけで簡単に歪みます。

1% Lowは、計測の中で最も遅い1%のフレームのフレームタイムを平均し、それを再びフレームレートに換算した値です。平均では答えられない問い、つまり悪い瞬間はどれくらい悪いのかに答えます。平均が120 FPSで1% Lowが45 FPSなら、100枚に約1枚のフレームが本来の3倍以上の時間を要しており、プレイヤーが引っかかりや入力の取りこぼしとして感じ取るのはまさにこの停止です。実用的な目安として、健全なシステムは1% Lowを平均のおよそ10〜20%以内に保ちます。それ以上に開きがある場合は、純粋な速度ではなくフレームの刻み方に問題があります。

デスクトップ作業、動画、ブラウジングでは、60 FPSあれば十分に滑らかです。ほとんどのディスプレイのリフレッシュレートと一致するためです。ゲームでは60 FPSはプレイ可能、120 FPSは動きの鮮明さと入力応答が明確に向上し、240 FPSは同じ高リフレッシュレートパネルを持つ競技プレイヤーに主に恩恵があります。パネルのリフレッシュレートを超えた分のフレームはほとんど破棄されるため、60Hz画面での90 FPSという結果は、見えるフレームが増えるというより、ティアリングの減少によって滑らかさに寄与します。最高値よりも安定性が重要で、1% Lowが55の固定60は、平均90で1% Lowが30より体感が良好です。

スタッターはほとんどの場合、平均値の不足ではなくフレームタイムの不均一から生じます。最も多い原因はバックグラウンド負荷です。動画を再生するセカンドモニター、大きなページをデコードするブラウザタブ、クラウド同期クライアント、システム更新はいずれもCPUとGPUの時間を断続的に奪います。2つ目の一般的な原因は熱または電力管理で、バッテリー駆動のノートPCや薄型筐体では負荷が続くとクロックが下がるため、計測が速く始まって1分以内に悪化することがよくあります。3つ目はフレームレート上限とリフレッシュレートの不一致で、60HzパネルでVSyncと60 FPS上限が互いに干渉し、目に見えるジャダーを生みます。

測定対象に対しては正確で、それはブラウザのレンダリングパイプラインが実際に画面へ届けているフレームレートです。Webアプリ、ブラウザゲーム、canvasやWebGLのシーンにとっては正しいツールです。すべてのフレームはブラウザ自身がタイムスタンプを付けるため、間隔は推定値ではなく実測値です。限界は精度ではなく範囲にあります。ブラウザは別ウィンドウのネイティブゲームの内部FPSカウンターを読めず、GPU使用率やクロック周波数を報告できず、クリック・トゥ・フォトン遅延も測定できません。また、OSとブラウザの双方が独自の負荷を加えるため、ベアメタルなベンチマークにはなり得ません。

この2つは混同されやすいですが、測っているものが違います。リフレッシュレートテストはパネルの上限、つまりディスプレイが物理的に1秒間に何回書き換えられるかを測ります。通常は60、120、144、240回で、ゴーストやフレームスキップの確認も行います。フレームレートテストは、その上限の中に実際にどれだけ届けられているかを測ります。この関係は重要です。パネルが144Hzでも実際に届くフレームレートが60なら、ボトルネックはディスプレイではなく、交換しても何も変わりません。まずリフレッシュレートテストで上限を確認し、次にフレームレートテストでその上限をどれだけ使えているかを見てください。

可能性の高い順に対処していきます。まず他のタブ、ビデオ通話、ランチャーを閉じ、再計測して低下のどこまでがバックグラウンド負荷だったかを確認します。次に計測中のCPUとGPUの使用率を確認します。コアが1つ占有されている、あるいはグラフィックスキューが詰まっているだけで、1% Lowが低くなる説明がつくことがほとんどです。3つ目に、OSの電源プロファイルを省電力からバランスまたは高パフォーマンスに切り替えます。これはバッテリー駆動のノートPCで特に重要です。4つ目にグラフィックスドライバーを更新し、ハイブリッドグラフィックスのノートPCがディスクリートGPUを使っていることを確認します。最後に、測定対象のページの描画負荷を下げます。

ブラウザタブ内で動作するゲームなら、HTML5、canvas、WebGL、WebGPUのいずれでも測定できます。これらはこのテストがサンプリングする同じアニメーションフレームのパイプラインを通して描画されるためです。別ウィンドウや全画面排他モードで動作するネイティブゲームは測定できません。Webページは他アプリケーションの内部にアクセスできないためです。ネイティブゲームでは、ゲーム内蔵のFPSオーバーレイやグラフィックスドライバーの機能、たとえばNVIDIA GeForce ExperienceやAMD Adrenalinのパフォーマンスオーバーレイを使ってください。ブラウザゲームとWebアプリにはこのテストを、ゲーム内テレメトリが必要なときはそれらのオーバーレイを使ってください。

フレームタイムは1枚のフレームの生成にかかる時間をミリ秒で表したもので、FPSは1秒に収まるフレームの枚数を数えます。両者は数学的に互いの逆数で、60 FPSなら1フレーム16.7ミリ秒、120 FPSなら8.3ミリ秒、144 FPSなら6.9ミリ秒です。スタッターを追いかけるうえでは、フレームタイムのほうが示唆に富む数値です。1秒まるごとを平均するのではなく、各フレームを個別に記述するからです。平均60 FPSの計測でも、40ミリ秒以上かかる個別のフレームが混ざっていることがあり、目が引っかかりとして読み取るのはまさにその長いフレームです。このテストはフレームタイムを直接報告するため、普通のカウンターでは隠れてしまう外れ値のフレームが見えるようになります。

平均が高くてもフレームタイムが不安定な計測は、低くても安定した計測より不快です。目は絶対速度よりも、刻み方の変化にはるかに敏感だからです。平均144 FPSでも10枚に1枚のフレームが30ミリ秒かかると、平均が健全に見えても動きは目に見えて揺れます。典型的な原因は、1つのCPUスレッドの飽和、シェーダーのコンパイル停止、テクスチャストリーミングの引っかかり、GPUを奪い合うバックグラウンドプロセスです。実用的な確認方法は、平均ではなく1% Lowとスタッター数を見ることです。1% Lowが平均の10〜20%以内なら刻み方は健全で、差がそれより広ければ、ボトルネックは純粋な性能ではなくスパイクにあります。

フレームレート上限は、アプリケーションがフレームを出せる枚数を制限するもので、通常は出力をディスプレイに合わせるために使います。VSync有効時の144Hz画面で141 FPSに上限を置くように、パネルのリフレッシュレートより少し下で制限するのは、入力遅延を削りながらティアリングを避ける標準的な方法です。G-SyncやFreeSyncのような可変リフレッシュレート対応ディスプレイでは、最大リフレッシュレート未満の上限がパネルを可変範囲内に保ち、固定リフレッシュレート動作への逆戻りを防ぎます。上限が有害になるのは、合理的な理由もなくシステム本来の出せる性能より低く設定したときだけです。その場合は実性能が遊んでしまいます。