FPSテスト
10秒間実行され、その間アニメーションを継続します。
ゲームやスクロールするページは、スペック上は滑らかに見えても実際に触るとカクつくことがあります。平均FPSは、まさにそうした体感を悪くする「コマ落ち」を覆い隠してしまう数値です。この無料ツールはブラウザ上で10秒間のフレームタイム計測を行い、体感を実際に説明できる数値——平均FPS、1%Low、フレームタイムのパーセンタイル、カクつき数、そして推定リフレッシュレート——を表示します。
仕組み
- 負荷の高い他の処理を閉じる. ダウンロードを一時停止し、負荷の高い他のタブやアプリを閉じて、このタブにフォーカスを移してください。バックグラウンドの負荷は、このテストが計測しているのと同じフレームを奪い合います。
- Startをクリックしてウォームアップさせる. 最初の数フレームは自動的に除外されます。描画が始まったばかりのアニメーションはまだ安定しておらず、代表的な値にならないためです。
- バーとフレームタイムの帯を見る. 動くバーとその下のフレームタイムの帯は、まさに計測対象そのものです。目に見えるジャンプやスパイクは、表示の不具合ではなく実際のコマ落ちです。
- 10秒間の計測が終わるまで待つ. テストは固定で10秒間実行されます。これにより1%Lowやパーセンタイルが、たまたま良かった・悪かった瞬間ではなく、十分な数のフレームに基づく安定した統計値になります。
- 平均・1%Low・カクつき数を確認する. 平均値は目立つ数字ですが、実際の体感をより正直に表しているのは、たいてい1%Lowとカクつき数のほうです。
- 推定リフレッシュレートと比較する. 結果は、ディスプレイの推定上限に対する相対評価になります。58fpsは60Hz画面では優秀な値ですが、144Hz画面では平凡な値です。
このテストがフレームレートを計測する仕組み
ブラウザが描画するすべてのフレームはrequestAnimationFrameを経由します。これは次の再描画の直前にコードを呼び出し、正確なタイムスタンプを渡すブラウザAPIです。このテストは連続するタイムスタンプ間の間隔を計測します——その間隔こそが、1フレームが実際に画面に届くまでにかかった物理的な時間であり、1秒間に何フレーム発生したかを数えて終わりにするよりもはるかに正直な数値です。
- 最初の数フレームは除外されます——マウント直後のアニメーション、テクスチャのアップロード、レイアウトの安定化はすべて、序盤のフレームを代表値にふさわしくないものにします。
- キャンバス上を動くバーと、その下のフレームタイムの帯は、まったく同じ計測ループの内部で描画されています——目に見えているものそのものが計測対象であり、並行して動く別のアニメーションではありません。
- 1回の実行は固定で10秒間続きます。これはまれなカクつきがノイズに埋もれることも、短すぎるサンプルを支配してしまうこともなく、実際の統計として現れるのに十分な長さです。
平均FPS・1%Low・フレームタイム:それぞれの数値の意味
単一の平均値は、示す以上に多くを隠してしまいます。9秒間非常に滑らかに動き、残り1秒だけ止まったような実行でも、平均を取ればそれなりに良い数値になります——だからこそこのテストは、1つではなく4つの異なる数値を報告します。
- 平均FPS:総フレーム数を総時間で割った値です。読み取りやすい反面、大多数の滑らかなフレームが少数の粗いフレームを覆い隠してしまい、簡単に「良く見せる」ことができます。
- 1%Low:実行中で最も遅い1%のフレームだけを対象にした平均フレームレートです。平均値よりも、実際に体感する「カクつき」にはるかに近い数値です。
- フレームタイムのパーセンタイル(p50/p95/p99):典型的なフレームにかかった時間と、最も悪い5%または1%のフレームだけが達したフレームタイムを比較したものです。両者の差は、一貫性を直接示す指標になります。
- カクつき数:ディスプレイのフレーム予算を大きく超える時間がかかったフレームの数です——人間の目が実際にコマ飛びとして認識できるフレームを指します。
平均FPSが隠してしまうカクつきの原因
平均値自体は問題ないのに1%Lowが低かったり、カクつき数が多かったりする場合、そのほとんどはハードウェアの性能上限ではなく、断続的な何かが原因です。
- バックグラウンドのタブやアプリがCPU/GPUを奪い合っている場合。特に自前で描画や動画のデコードを行っているものが該当します。
- ブラウザのハードウェアアクセラレーションがオフになっており、コンポジット処理がCPUだけに押し付けられている場合。
- GPUドライバーが古い、または不整合を起こしている場合。特にWindowsのアップデート直後に起こりがちです。
- ノートパソコンでのサーマルスロットリング——テストやゲームを長く実行するほどカクつきが悪化し、休ませると回復する場合は、熱による制限が強く疑われます。
- 省電力モードがCPU/GPUのクロックを制限している場合。バッテリー駆動のノートパソコンでよく見られます。
- ブラウザ拡張機能がすべてのページにスクリプトを挿入しており、フレームごとにわずかながら実際のコストを加えている場合。
ブラウザがリフレッシュレートを直接読み取れない理由(「推定」の意味)
ディスプレイのリフレッシュレートを直接取得できるWeb APIは存在しません——呼び出せるnavigator.refreshRateのようなものはないのです。代わりにこのツールが行っているのは、描画のリズムそのものから推定することです。フレームが滑らかに届いているとき、そのほとんどは1つの間隔の周辺に密集し、その間隔がほぼ確実にディスプレイの実際のフレーム予算だと言えます。
- 信頼度が高い:大多数のフレームが、一般的なリフレッシュレート(60/75/90/100/120/144/165/240Hz)に一致する、明確な1つの間隔の狭い範囲に収まっている状態です。
- 信頼度が中程度または低い:フレームがより分散している状態です。テストに何かが干渉したか、そもそもディスプレイが一定のレートを保っていないことが原因です。
- 「判定できませんでした」という結果自体にも意味があります——たいていはテストが中断されたか、パネルがアダプティブシンクを使用していることを示しています(詳しくは後述)。
アダプティブシンク:G-Sync、FreeSync、VRR
可変リフレッシュレート(VRR)——NVIDIAのG-Sync、AMDのFreeSync、あるいは単に「アダプティブシンク」として販売されている機能——は、1つの固定レートを保つ代わりに、GPUが出力するものに合わせてディスプレイのリフレッシュ間隔を意図的に変化させます。これは欠陥ではなく本物の機能です。GPUの出力とディスプレイの固定スケジュールとのずれをなくすことで、不安定なフレームレートをより滑らかに感じさせるために、あえて設計されたものです。
VRR対応のパネルでは、このテストのリフレッシュレート推定が低信頼度として返ってくることがよくありますが、それは正しい挙動です——ディスプレイが1つの間隔を保っていない以上、固定できる間隔自体が存在しないためです。これは不具合ではなく、テストが意図どおりに動作している証拠です。それより上にあるフレームタイムの統計(平均、1%Low、カクつき数)には影響がなく、引き続き意味のある数値です。
よくある対処法:ハードウェアアクセラレーション、ケーブル、リフレッシュレート設定
- Windows:「設定」→「システム」→「ディスプレイ」→「ディスプレイの詳細設定」で、リフレッシュレートが実際にパネルの最大値に設定されているか確認してください。ドライバーを新規インストールしたり、ケーブルを交換したりすると、気づかないうちに60Hzへリセットされることがあります。
- ProMotion(120Hz)搭載のmacOS:「システム設定」→「ディスプレイ」で、リフレッシュレートが固定60Hzではなく、動的/高リフレッシュレートのオプションに設定されているか確認してください。
- 外付けモニターが定格のリフレッシュレートに達しない場合:ケーブルとポートが重要です。高解像度で高いリフレッシュレートを出すには、DisplayPort、あるいは十分新しいバージョンのHDMIが必要で、箱に入っていたケーブルをそのまま使うだけでは不十分なことがあります。
- ブラウザ側:設定でハードウェアアクセラレーションが有効になっているか確認し、カクつきが続く場合は拡張機能を1つずつ無効化して試してください。
- ノートパソコンの場合:テスト前に電源に接続し、電源プランを「最高のパフォーマンス」に設定してください。省電力モードは、よくある目に見えない制限だからです。
このテストではないもの
これはフレームタイムの診断ツールであり、GPUベンチマークでも専用のリフレッシュレート計測器でもありません。比較可能なスコアを出すためにグラフィックカードへ負荷をかける重い3Dシーンをあえて描画しませんし、専用のハードウェアツールのようにパネルの正確なレートを読み取れるとも主張しません——描画のリズムから推定しているだけであり、その事実は結果全体を通して正直に「推定値」として明示されます。
よくある質問
テストを実行するたびにFPSの数値が変わるのはなぜですか?
実行ごとに多少のばらつきが出るのは正常です——バックグラウンドのプロセス、熱の状態、他に開いているものなどが、実行のたびにわずかに変化するためです。大きく変動する場合は、たいてい何かが断続的にリソースを奪い合っています。他のタブやアプリを閉じてから、もう一度テストしてみてください。
どのくらいのFPSがあれば「良い」と言えますか?
絶対的な数値ではなく、あなたのディスプレイ次第です——58fpsは60Hz画面では優秀ですが、144Hz画面では平凡です。だからこそこのツールは、固定のしきい値ではなく、推定したリフレッシュレートに対する相対評価で結果を判定します。
60Hz画面なのに、テストの結果がぴったり60ではなく58 FPSになるのはなぜですか?
理論上の最大値より数フレーム少ないのはまったく正常です——数学的に完璧で揺らぎのない間隔で描画されるものなど存在しません。実際に問題があるかどうかは、平均値付近のわずかなばらつきではなく、1%Lowとカクつき数が示します。
「1%Low」とは何ですか?平均FPSよりも重要なのはなぜですか?
実行中で最も遅い1%のフレームだけを対象にした平均フレームレートです。平均が高いのに1%Lowが低い場合、大部分は滑らかだったものの、実際にはっきり分かるカクつきが発生したことを意味します——これはまさに、単一の平均値では見えてこないものです。
このテストでGPUの実際の性能を測定できますか?
直接的には測定できません——このテストが測っているのは、ブラウザが軽量なキャンバスアニメーションをどれだけ一貫して描画できるかであり、これは主に表示パイプラインや同時に発生している負荷を反映するもので、重い3D描画時のグラフィックカードの性能上限ではありません。専用のGPUベンチマークは、それとは別の、より負荷の高いツールです。
ブラウザがモニターの正確なリフレッシュレートを教えてくれないのはなぜですか?
それを公開するWeb APIが存在しないためです。このツールはフレームが実際に届く様子から推定しているため、結果は常にハードウェアからの直接的な読み取り値ではなく、信頼度付きの推定値として表示されます。
タブを切り替えたりウィンドウを最小化したりするとFPSが下がるのはなぜですか?
ブラウザは電力とCPUを節約するため、バックグラウンドのタブの動作を制限します。だからこそ、実行中にタブがバックグラウンドに移動すると、このテストは中止してやり直しを求めます——バックグラウンドのタブから得られた結果には意味がないからです。
このテストはバッテリーを消耗させたり、デバイスを過熱させたりしますか?
他の10秒間のアニメーションと変わりません。重い3Dシーンではなく、シンプルな2Dのキャンバスを描画しているだけで、計測時間が終われば自動的に停止します。
同じパソコンなのに、Chrome、Firefox、Safariで結果が異なるのはなぜですか?
それぞれのブラウザは独自のコンポジターとスケジューリングの挙動を持っており、拡張機能、ハードウェアアクセラレーションの初期設定、アップデートの頻度もブラウザごとに異なります——ある程度のばらつきは想定内であり、どれかのブラウザが壊れているという意味ではありません。
カクつき(jank)とは正確には何ですか?
ディスプレイのフレーム予算を大きく超える時間がかかって届いたフレームのことです——人間の目が滑らかな動きではなく、コマ飛びやカクつきとして認識できるほど長い遅れを指します。
このテストはすべてあなたのデバイス上で完結します——キャンバスアニメーションを描画し、あなた自身のブラウザのフレームを計測しているだけです。フレームのデータ、タイミング、結果が外部にアップロード、送信、保存されることは一切ありません。