デベロッパーからのフィードバックが必要 - Frame Timing API

ここ数年、ブラウザはレンダリング パフォーマンスの面で、特にモバイルにおいて大きな進歩を遂げました。以前は、複雑なシーンでスムーズなフレームレートを実現することは不可能でしたが、現在は、注意深く行えば実現できるようになりました。

ただし、ほとんどのユーザーにとって、自分のデバイスで合理的にテストできる内容と、ユーザーが実際に体験する内容には違いがあります。60 fps でスムーズに再生されなければ、ユーザー エクスペリエンスが損なわれ、最終的には他のプラットフォームに移行し、YouTube の損失につながります。W3C では、ユーザーが何を見ているかを把握するのに役立つ新しい API（Frame Timing API）について議論されています。

Jake Archibald と私は最近、この API の概要を動画で録画しました。動画で確認したい場合は、以下をご覧ください。

Frame Timing API の用途

Frame Timing API には、さまざまな用途があります。特に、プロジェクトにとって重要なものを測定できます。それでも、次のような方法があります。

  • JavaScript と CSS アニメーションの fps のトラッキング。
  • ページのスクロールの滑らかさ（または、無限スクロール リストの使い勝手）をトラッキングする。
  • デバイスの現在の負荷に基づいて、Showbiz エフェクトを自動的にスケールダウンする。
  • ランタイム パフォーマンス指標の回帰テスト。

エレベーター ピッチ

仕様で現在定義されている API は次のとおりです。この API を使用すると、レンダラ スレッドのタイミング（JavaScript、スタイル、レイアウトの実行場所）に関するデータを取得できます。（レンダラ スレッドはメインスレッドとも呼ばれますが、これは別名です）。

var rendererEvents = window.performance.getEntriesByType("renderer");

返されるレンダラ スレッド レコードは、おおよそ次のような形式になります。

    {
      sourceFrameNumber: 120,
      startTime: 1342.549374253
      cpuTime: 6.454313323
    }

各レコードは基本的に、一意のフレーム番号、フレームの開始時間の高解像度タイムスタンプ、使用した CPU 時間のタイムスタンプを含むオブジェクトです。これらの配列を使用すると、各 startTime 値を確認し、メインスレッドが 60 fps で動作しているかどうかを確認できます。つまり、「各フレームの startTime は約 16 ms のチャンクで増加していますか？」ということです。

さらに、cpuTime も取得できるため、16 ms の境界内に余裕で収まっているか、ギリギリだったかを確認できます。cpuTime が 16 ms の境界付近にある場合、ガベージ コレクションなどの処理を行う余裕がほとんどなく、CPU 使用率が高くなるとバッテリー消費も増加します。

レンダラ スレッドに加えて、ペインティングと合成が行われるコンポジタ スレッドのタイミングに関するデータも取得できます。

var compositeThreadEvents = window.performance.getEntriesByType("composite");

これらの各イベントにはソース フレーム番号も返されます。この番号を使用して、メインスレッドのイベントに関連付けることができます。

{
    sourceFrameNumber: 120,
    startTime: 1352.343235321
}

ブラウザでコンポジットが機能する仕組み上、レンダラ スレッド レコードごとに複数のこのようなレコードが存在する場合があります。sourceFrameNumber を使用して、それらを再び結び付けることができます。また、これらのレコードに CPU 時間を含めるかどうかについても議論が交わされています。ご意見がある場合は、GitHub の問題で発言してください。

詳細

この API はまだリリースされていませんが、まもなくリリースされる予定です。ご利用を開始するまでの間、以下の情報をご確認ください。