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

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

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

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

Frame Timing API の用途

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

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

エレベーター ピッチ

仕様で現在定義されている 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 はまだリリースされていませんが、まもなくリリースされる予定です。ご利用の間は、以下の資料や情報をご参照ください。