フィルターの更新に時間がかかる、メニューがすぐ開かない、入力した文字が遅れて表示される。ページの読み込みが速くても、こうした問題は起こります。操作後の応答と JavaScript の処理を調べましょう。Worker や iframe を使うアプリケーションでは、メッセージのやり取りも確認します。
読み込みが速くても操作への応答が遅くなる理由
クリック後、ブラウザーはイベントを処理し、JavaScript を実行して、更新されたフレームを表示する必要があります。メインスレッドがビジー状態の場合、一部の作業は順番を待ちます。したがって、読み込み速度が優れていても、メニュー、フィルター、フォームの応答が速いとは限りません。
計算を Web Worker に移すとメインスレッドの負荷を減らせますが、データ交換が必要になります。ページのウィンドウ、Worker、iframe は postMessage() でメッセージをやり取りします。送信済みのメッセージも、処理を待つ場合があります。
メッセージキューで遅延が発生する場所
まずは考えられる 3 つの理由から考えてみましょう。
- 受信側は長時間実行される同期タスクを実行しています。新しいメッセージは、スレッドが空くと処理されます。
- メッセージが多すぎます。短時間で終わるハンドラーでも、処理よりも早く作業が到着するとキューが作成されます。
- 大量のデータが転送されます。送信側でのシリアル化と受信側での逆シリアル化には、それぞれのスレッドで時間がかかります。
たとえば、文字を入力するたびに検索リクエストを Worker に送るとします。前の検索結果をまだ計算中なら、後続のリクエストがたまります。利用者が入力を終えても、アプリケーションは古い入力の結果を計算し続けるかもしれません。メッセージの頻度、処理時間、転送量を測定しましょう。
INP がページの応答を測定する方法
INP（Interaction to Next Paint）は、訪問中のクリック、タップ、キー入力に対する応答性を評価します。外れ値の除外規則に従い、特に遅い操作の一つが結果に反映されます。個々の操作の遅延は、処理開始までの待ち時間、ハンドラーの実行時間、次のフレームが表示されるまでの時間で構成されます。
良好な INP は 200 ミリ秒以下です。200 ミリ秒を超え 500 ミリ秒以下なら改善が必要で、500 ミリ秒を超えると不良です。サイトの評価では、モバイルとデスクトップを分け、訪問ごとの INP の第 75 パーセンタイルを確認します。
メッセージ キューの処理がメイン スレッドを占有し、入力やレンダリングを妨げる場合、メッセージ キューがこの遅延の原因となる可能性があります。ただし、ワーカーの応答時間を自動的に INP とみなすことはできません。
検索に戻りましょう。入力した文字はすぐに表示され、結果は後で更新されます。有用な作業はまだ完了していませんが、次のフレームはすでに表示されています。このようなシナリオでは、入力に対する応答と実際の結果が得られるまでの時間を個別に測定します。高速読み込みインジケーターは、検索自体が高速になったことを証明するものではありません。
Milten での INP チェックと JavaScript 分析
INP Scannerは、テスト中の操作の遅延を調べるのに役立ちます。メニュー、商品一覧、フォーム、カートなど、問題の操作があるページを選びます。実行された操作と報告された原因を確認してください。結論が当てはまるのは、その試行と条件です。
JS Scannerは、クリックやスクロールをせず、Chromium で一つのページを読み込む際の JavaScript を分析します。スクリプトのサイズと読み込み、コード実行、長いタスク、エラー、異なるホスト名のスクリプトを確認できます。利用可能なソースマップがあれば、バンドル内のモジュールも表示できます。
レポートを比較して、検査する領域を選択します。 JS Scanner の重いファイルは、ページを開始するときの負荷を説明する可能性がありますが、その存在がクリックが遅い原因をまだ証明していません。ロード後の動作は別途再現する必要があります。どちらのツールも検索を絞り込むのに役立ちます。すべてのウィンドウとワーカー間のすべてのメッセージのトレースは提供されません。
読み込み中に実行されなかったコードは、クリック後または別のページ状態で必要になる場合があります。削除する前に、これらのスクリプトを確認してください。異なるホスト名のスクリプトも必ずしも不要というわけではありません。プロジェクト独自の CDN がこのグループに分類される可能性があります。
INP が悪い原因を調べる
- 再現手順を記録します。ページ、デバイス、インターフェイスの状態を指定します。たとえば、カタログを開いてクエリをすばやく入力し、フィルターを選択します。
- RUM または CrUX がある場合は、フィールド データを使用して最も顕著な問題を選択します。ラボでの測定は、実際の訪問の統計に代わるものではありません。
- INP チェックを実行し、レポートの対象範囲と問題のあるアクティビティを照合します。再現されていない場合は別途ブラウザでご確認ください。
- JS Scanner を介して JavaScript の読み込みを調べます。遅延と重複する可能性がある疑わしいファイルと長いタスクを選択します。
- 問題のあるシナリオを DevTools に記録します。 Worker または iframe の場合、送信されるメッセージ、開始された処理、応答、および画面の更新を追跡します。リクエスト ID は、古い入力に対する応答と現在の入力に対する応答を区別するのに役立ちます。
- 修正後、同じデバイス、CPU、ネットワーク設定で同じ手順を繰り返します。複数の実行を比較し、蓄積されるフィールド データを確認します。
INPを最適化するために何を変更するか
INP の最適化は、次のフレームを遅らせる処理を減らすことから始めます。同期ハンドラーの仕事量を減らし、長いタスクを分割して、必須ではない計算の前に視覚的な応答を表示できるようにします。
Worker を含むアプリケーションでは、送信されたすべての作業が必要かどうかを確認してください。検索では、頻繁な更新を集約し、古い結果を破棄できます。インターフェースの動作に従って送信遅延を選択します。デバウンスが多すぎると、ユーザーの検索自体が遅くなります。
受信側に必要なデータだけを送ります。フィルターの変更後に、商品一覧全体ではなくクエリパラメーターだけを渡せば十分な場合もあります。適したバイナリデータには、転送可能オブジェクトを検討してください。所有権が移り、転送後のバッファーは送信側で使えなくなる点に注意します。
各仮説を個別にテストします。メッセージのサイズを減らした場合は、送信時間と処理時間を比較してください。計算を移動した場合は、インターフェイスの応答と結果が得られるまでの時間を確認してください。これにより、どの編集が役に立ったかが表示されます。
キューの過負荷を自動的に確認することはできますか?
WICG の提案は現在、ドキュメントと Worker のタスクキューの継続的な混雑を検出するため、Long Animation Frames API の拡張を目指しています。メッセージごとの時間やシリアル化コストの測定は、現在の拡張案には含まれません。
この提案は実験段階です。初期資料にある delayed-message の観測例を、診断に必須の手段として扱わないでください。再現できる操作手順、INP Scanner、JavaScript の分析、DevTools の記録から始めましょう。遅い操作を一つ選び、利用者が必要とする結果までの経路を追います。
