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

ここ数年で、ブラウザは特にモバイルにおいて、レンダリング パフォーマンスにおいて飛躍的な進歩を遂げました。これまでは、遠隔地の複雑な処理でスムーズなフレームレートを実現できるとは望んでいませんでしたが、今では気をつければ少なくとも実現可能です。

しかし、ほとんどの人にとっては、自社のデバイスで合理的にテストできるものと、ユーザー エクスペリエンスの間にずれがあります。滑らかな 60 fps で撮影されないと、ゲーム エクスペリエンスが損なわれ、最終的には他のゲーム エクスペリエンスに悪影響を及ぼします。また、W3C では、ユーザーに表示される内容を確認するのに役立つ新しい API、Frame Timing API について検討しています。

Jake Archibald と先日、API の概要に関する動画を録画しました。テキストを読むよりも、以下の動画をご覧になることをおすすめします。

Frame Timing API の使用

Frame Timing API でできることは間違いなくたくさんあります。そして、最も重要なのは、自身とプロジェクトにとって何が重要かを測定できることです。そのためのアイデアをいくつかご紹介します。

  • JavaScript と CSS アニメーションの FPS のトラッキング。
  • ページ スクロールのスムーズさ(または便利な無限スクロール リスト)をトラッキングします。
  • デバイスの現在の負荷に基づいて、ショービジネス効果を自動的に縮小します。
  • ランタイム パフォーマンス指標の回帰テスト。

エレベーター ピッチ

この API の現在の仕様は次のようになります。この API を使用すると、JavaScript、スタイル、レイアウトが実行されるレンダラのスレッドのタイミングでデータを pull できます。(レンダラ スレッドを「メインスレッド」と呼んでいる方もいらっしゃるかもしれませんが、別の名前で同じスレッドです。)

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

返される各レンダラ スレッドの記録は、おおむね次のようになっています。

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

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

さらに、cpuTime も得られるため、16 ミリ秒の境界内に無理なく収まっているか、最後まで行っていたかがわかります。cpuTime が 16 ミリ秒の境界に近い場合、ガベージ コレクションが行われる余地はあまりなく、CPU 使用率が高いためバッテリー消費量も増加します。

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

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

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

{
    sourceFrameNumber: 120,
    startTime: 1352.343235321
}

ブラウザでの合成の性質上、レンダラ スレッドのレコードごとにこれらのレコードが複数存在する場合があるため、sourceFrameNumber を使用してそれらを結び付けることができます。また、これらのレコードにも CPU 時間を含めるかどうかについてもディスカッションを行いますので、GitHub の問題について強く言いましょう。

詳細

この API はまだリリースされていませんが、近日中にリリースされる予定です。それまでの間、以下をご覧になるか、またはできることを以下にご紹介します。