自動キャリブレーションのタイミング分析、ライブのフレーム時間グラフ、カメラで検証できる番号マーカー — 「開始」をクリックすれば、リフレッシュ間隔は自動で求まります。
すべてブラウザ内で実行されます · 何も記録・アップロードされません
最終更新: · 最新のブラウザAPIに基づいて正確性を確認済み
On this page
最初の1秒ほどで実際のリフレッシュ間隔が自動的に求まります — モニターのHzを入力する必要はありません。
短い実行では単に運良くスキップがゼロになることがあります。長く実行するほど正直な結果が得られます。
想定フレーム時間に近い平らな線が健全な状態で、高いスパイクはその場で検出されたスキップです。
このテストが見られるのはブラウザ側の遅延だけです — システムの負荷が原因であることが多く、修正も簡単です。
このテストがきれいでも動きに違和感が残る場合、マーカーのスローシャッター写真でこのテストには見えないディスプレイ自体の表示を確認できます。
requestAnimationFrameへの呼び出しはそれぞれタイムスタンプを返すため、このテストは固定の数値を仮定するのではなく、連続するタイムスタンプ間の差を測定します。最初の数十フレームについてこれらの差を集め、その中央値を実際のリフレッシュ間隔として求めます — 60Hzディスプレイで約16.7ms、144Hzで約6.9msといった具合です。これにより、モニターの定格にかかわらず、何も入力せずに同じ方法で動作します。
このキャリブレーション期間が終わると、想定間隔より明らかに長い間隔（1.5倍を超えるもの）はスキップとして記録され、スキップしたフレーム数はその間隔が想定よりどれだけ長かったかから求められます。上の番号マーカーは、ブラウザが実際にレンダリングしたフレームごとに1つずつ進みます。これが写真に意味を持たせる理由です — 本物のスキップは画面上の単なる数字ではなく、数字の重複や欠落として現れます。
このツールを過大評価させないためにも、正直に伝える価値があります。ここで数えられるフレームスキップは、ブラウザ自体が新しいフレームをスケジュールどおりに画面へ渡せなかったことを意味し、通常はメインスレッドが他の処理で忙しくタイミングを逃したことが原因です。これは実際によくある、見える意味でのスタッタの原因であり、このテストが捉えようとしているまさにその種のドロップです。
このテストが見られないのは、パイプラインのさらに下流、モニター自体の中で起きるフレームスキップです。パネル自体のスケーラーは、ブラウザが完全に正しく時間どおりに配信したフレームを静かに重複表示できます — ブラウザの視点からは何も問題は起きていないのに、画面はまだスタッタします。そのようなフレームスキップが起きた時点で、ブラウザはすでに自分の仕事を終えているため、ブラウザのタブで動くどんなJavaScriptもそれを観測することはできません。
このテストの報告内容とは別に、モニターが実際に何をしているかを確認する実用的な方法はスローシャッター写真です。スマホのカメラのシャッター速度を1回のリフレッシュ間隔より遅く設定し — 60Hzディスプレイならおおよそ1/60秒より遅く — テストを実行しながら番号マーカーを撮影してください。
結果の軌跡の中で数字が均等な間隔ではっきり分かれていれば、パネルは一定のペースでフレームを表示しています。数字が抜けていたり、同じ数字が2回現れたりする場合は、パネル自体がフレームをスキップまたは重複していることを示しており、このブラウザ側のカウンターでは単独では捉えられないハードウェアレベルの問題です。
ブラウザ側では、他の処理で忙しいCPU、リソースを奪い合うバックグラウンドのタブやプログラム、メインスレッドを一瞬止めるガーベジコレクションの一時停止、合成処理に追いついていないGPUなどが原因です。古いグラフィックドライバーはこの最後の要因をより起こりやすくするので、NVIDIA、AMD、Intelのいずれかで最新版を使っているか確認する価値があります。これらのいずれも、ブラウザが新しいフレームを渡すタイミングを逃す原因になり、このテストは正しくそれを捉えます。
ディスプレイ側では、選んだ解像度とリフレッシュレートを両方フルに支えられないケーブルやポート（よくある例は120Hzの4Kを60Hzの4Kしか扱えないポートで送ること。静かにフォールバックしたりスキップしたりします）、パネルが確実に維持できないレートまで上げられたリフレッシュレート、モーションスムージングのようなフレームタイミングに干渉する積極的な映像処理などです。これらは上記のカメラ方式でしっかり確認する必要があるタイプで、同じ処理がゴースティングテストが確認する余分なブラーの一般的な原因でもあります。
この2つは異なる問いに答え、組み合わせるとよく機能します。リフレッシュレートテストは、ディスプレイが現在実際にどのレートで動作しているかを教えてくれます — 本当に144Hzなのか、それとも静かに60Hzへ落ちているのか。このテストは検出されたレートが正しいと仮定した上で、そのレートでのすべてのフレームが実際にスケジュールどおりに届いているか、それともスキップや重複が起きているかを問います。ディスプレイは片方には合格し、もう片方には失敗することがあります。
リフレッシュレートテストはディスプレイが実際にどのレートで動作しているかを教えてくれます。このテストは、そのレートでのすべてのフレームが本当にスケジュールどおりに配信されているか、それともスキップや重複が起きているかを確認します。
いいえ。このテストが見ているのはパイプラインのブラウザ側だけです。モニター自体のスケーラーは正しく配信されたフレームを静かに重複表示することがあり、ブラウザベースのテストではそれを見ることができません — 動くマーカーのカメラによる長時間露光写真が確認する実用的な方法です。
このテストはディスプレイのリフレッシュレートを尋ねるのではなく、最初の数十フレームを測定してそこから実際の間隔を求めます。これにより、60Hz、144Hz、240Hzのどの画面でも、設定不要で同じように機能します。
ブラウザ側では、CPUの負荷、バックグラウンドのプログラム、ガーベジコレクションの一時停止、追いついていないGPUなどです。ディスプレイ側では、ケーブルやポートの制限、オーバークロックされたリフレッシュレート、積極的な映像処理などです。
長時間の実行中にたまに単発のスキップが起きるのは通常心配する必要はありません。頻繁に繰り返されるスキップの方が、対応する価値のある意味のある信号です。
いいえ。すべてのタイミング分析はブラウザ自身のアニメーションクロックを使ってローカルで行われます — 何も取得・記録・送信されません。
フレーム配信は動きの品質全体の一部にすぎません。これらでその他の部分を確認できます。
