The #ChromeDevSummit site is live, happening Nov 12-13 in San Francisco, CA
Check it out for details and request an invite. We'll be diving deep into modern web tech & looking ahead to the platform's future.

入力レイテンシの推定

監査が重要である理由

ユーザーが体感するアプリのパフォーマンスは、入力時のレスポンスの速さに大きく左右されます。 アプリでは、ユーザーの入力に対して 100ms 以内に応答するようにしてください。それ以上の時間を要すると、ユーザーは反応が悪いアプリだと感じます。 詳細については、Measure Performance with the RAIL Model をご覧ください。

この監査テストの目標スコアが(RAIL モデル推奨の 100ms ではなく) 50ms とされている理由については、このドキュメントの監査テストの目的のセクションをご覧ください。

監査に合格する方法

ユーザー入力に対するアプリの応答速度を上げるためには、ブラウザでのコードの実行方法を最適化する必要があります。 一連のテクニックについては、レンダリング パフォーマンスのドキュメントをご覧ください。 具体的には、演算処理を Web Worker に委ねてメインスレッドを開放する、CSS セレクターをリファクタリングして演算量を減らす、CSS プロパティを使用してブラウザに負荷がかかる操作を最小限にするなど、さまざまな方法が紹介されています。

なお、この監査では全体的な入力レイテンシは測定していない点に注意してください。 このドキュメントのテストの目的で説明しているとおり、この監査で測定しているのは、アプリがユーザー入力に応答するまでの厳密な時間ではありません。 言い換えると、画面表示も含めて、アプリがユーザー入力に対して応答を完了するまでの時間を計測しているわけではありません。

この時間を手動で計測するには、Chrome DevTools の Timeline を使用して記録をとります。 詳細は Timeline ツールの使い方をご覧ください。 基本的には、記録を開始して、計測するユーザー入力操作を実行し、記録を停止します。その後、フレーム チャートを解析して、全段階のピクセル パイプライン が 50ms 以内に完了していることを確認します。

監査方法

このセクションでは Lighthouse による監査方法と監査スコアの算出方法を説明します。

RAIL パフォーマンス モデルでは、ユーザー入力に対する応答時間を 100ms 以内にするよう推奨しています。一方、Ligjthouse の目標スコアは 50ms です。 なぜでしょうか。

理由は、Lighthouse ではユーザー入力に対するアプリの応答性を評価する際に、プロキシ メトリックを使用してメインスレッドの利用可否を確認しているためです。 Lighthouse では、アプリがユーザー入力に完全に応答するまで(任意の JavaScript の実行から、物理的に画面に新しいピクセルを描画するまで)50ms を要すると想定しています。 よって、50ms 以上メインスレッドが利用できないと、アプリで応答を完了するための時間が足りなくなります。

ユーザーの入力時に、Lighthouse で報告される遅延時間(またはそれ以下の遅延時間)が発生する確率は 90% です。 残りの 10% のユーザーにおいては、さらに長時間の遅延が発生する可能性があります。