Core/Dashのディメンション： Load State（INP）

ディメンション：Load State INP（inpls）

Load State（INP）ディメンションは、ユーザーインタラクションがキャプチャされたまさにその瞬間のdocument ready stateを記録します。Chrome User Experience ReportにおけるすべてのINPイベントには、loading、dom-interactive、dom-content-loaded、completeのいずれかのロード状態タグが付与されています。CoreDashはこのタグを、フィルターやグループ化が可能なディメンションとして表示します。これにより、生のINPスコアだけでは答えられない次の疑問に答えることができます。『ページのライフサイクルのどの時点で最悪のインタラクションが発生したのか？』

この疑問は、まったく異なる2つの技術的な解決策の分かれ目となります。loading中に集中しているINPの問題には、JavaScriptの遅延実行戦略が必要です。complete中に集中しているINPの問題には、イベントハンドラーの処理削減、フレームワークのオーバーヘッド削減、または実行時コード内のlong taskの分割が必要です。ロード状態によるグループ化を行えば、手動でコードを実装することなく、この切り分けが可能になります。

CoreDashが監視しているサイトのデータ全体におけるロード状態別のINPインタラクションの分布は、おおよそ次のとおりです。loading 15%、dom-interactive 20%、dom-content-loaded 25%、complete 40%。インタラクションの大部分はページの読み込みが完了した後に発生しますが、最悪のINPスコアは圧倒的に初期のステートに集中しています。

スクリーンショット

なぜロード状態がINPにおいて重要なのか

Interaction to Next Paintメトリックは、ユーザーインタラクション全体のレイテンシ（入力遅延、イベントハンドラーの処理時間、および次のフレームが描画されるまでのプレゼンテーション遅延）を測定します。これら3つのコンポーネントのうち、入力遅延は、ユーザーがクリックまたはタップした瞬間にブラウザが実行している処理から最も直接的な影響を受けます。

ページの読み込み初期段階では、main threadの競合が最大に達します。ブラウザはHTMLをパースし、同期スクリプトを実行し、CSSOMを構築し、parser-blockingリソースを実行し、レンダリングサイクルを立て続けにトリガーしています。main threadにおけるすべてのlong taskは、ユーザーインタラクションがキューに入れられ、待機する時間枠となります。この待機時間が入力遅延であり、ページの読み込み段階でINPが悪化する主要な要因です。

document.readyStateがcompleteに達した後に発生するインタラクションは、負荷の落ち着いたmain threadで処理されます。ブラウザの読み込みはすでに完了しています。この段階で依然としてINPが悪い場合、原因は読み込み時の競合ではありません。ユーザーの操作に応じてページが実行するJavaScriptに原因があります。肥大化したイベントハンドラー、フレームワークの再レンダリングサイクル、スクリプトによってトリガーされるレイアウトスラッシング、あるいはインタラクション中に同期実行される最適化されていないサードパーティ製コードなどです。

ロード状態は、これら2つの根本原因を切り分けるための最も迅速なフィルターです。

各ロード状態

loading

ページはまだHTMLドキュメントのパースを完了していません。main thread isは同期スクリプトを実行し、parser-blockingリソースを取得し、初期のDOMを構築しています。これはユーザーインタラクションにとって最も過酷な環境です。いかなるlong taskも、ブラウザがクリックやタップを処理するのを直接ブロックするため、入力遅延は最大になります。この時間枠にインタラクションを行うユーザーは、通常、最もせっかちな訪問者であるか、高速な回線を利用していてページの読み込みが終わる前に表示コンテンツに到達したユーザーです。彼らのINPスコアは、収集されるデータの中で最悪のものになります。応答性の悪いINPイベントのかなりの割合がloadingステートである場合は、重要ではないスクリプトをdeferまたはasyncに移動し、ファーストビューにおけるparser-blockingリソースを排除してください。

dom-interactive

HTMLが完全にパースされ、DOMが構築されると、document.readyStateはinteractiveに達します。ただし、画像、スタイルシート、遅延スクリプトなどのサブリソースはまだ読み込み中です。この時点で遅延スクリプトが実行を開始するため、main threadは引き続き非常にビジーになる可能性があります。フレームワークのハイドレーションも多くの場合、この段階で開始されます。ユーザーにとってはページが準備完了に見える一方で、main threadはまだビジーであるため、これは危険な時間帯です。入力遅延は高い水準のまま推移します。INPの悪化がここに集中している場合、その解決策はloadingと同じです。DOMパース完了の直後に実行される同期処理の量を減らしてください。

dom-content-loaded

DOMContentLoadedイベントが発火した状態です。DOMは完成し、遅延スクリプトの実行も完了しています。ほとんどのJavaScriptフレームワークは、この時点までに初期ハイドレーション処理を完了しています。main threadの負荷が下がり、インタラクションに対する応答が速くなり始めます。このステートにおけるINPスコアは、通常、前の2つのステートよりは良好ですが、completeに比べるとまだ高い数値を示します。ここに応答性の悪いインタラクションが集中している場合は、フレームワークやアプリケーションスクリプトがDOMContentLoadedハンドラーで行っている処理を確認し、タスクの合間に入力処理を行えるよう、ハイドレーション処理を分割（chunk）したりyieldしたりできないかを検討してください。

complete

画像、フォント、サードパーティのiframeを含むすべてのリソースが読み込まれると、document.readyStateはcompleteに達します。これが、セッションの残りの時間においてページが動作する定常状態です。このステートでのINPの悪化は、純粋な実行時の問題です。ページの読み込みは完了しています。この段階でもなおmain threadがインタラクションをブロックしている場合、原因は操作時のJavaScript実行にあります。具体的には、イベントハンドラーが同期的な処理を多く行いすぎている、フレームワークの更新が負荷の高いレイアウトの再計算をトリガーしている、あるいはサードパーティスクリプトが継続的にlong taskを実行していることなどです。対策は遅延処理ではなく、ユーザーが実際にクリックしたときに発生する処理のコストを減らすことです。

デバッグのワークフロー

ステップ1：CoreDashでロード状態によるフィルターを適用する。INPの内訳テーブルを開き、Load Stateでグループ化します。応答性の悪い（200ms超の）インタラクションの割合が最も高いステートを特定してください。これにより、読み込みの問題なのか実行時の問題なのかが即座に分かります。

ステップ2：URLおよびデバイスとクロスリファレンスする。Load StateディメンションとURLディメンションを組み合わせて、読み込み初期段階で応答性の低いインタラクションが発生している具体的なページを特定します。モバイルデバイスはCPUが遅く、すべてのlong taskの処理時間が延びるため、読み込み時に不釣り合いなほど大きな影響を受けます。

ステップ3：ステートに適した対策を適用する。loadingおよびdom-interactiveについては、Optimize INPガイドを使用してスクリプトの読み込み戦略を監査してください。スクリプトをdeferに移動し、render-blockingリソースを排除し、scheduler.yield()を使用して長い初期化タスクを分割します。completeについては、Chrome DevToolsでイベントハンドラーをプロファイリングし、インタラクションごとにトリガーされる同期処理のワークロードを削減します。

エンジニアリングの経験則

応答性の悪いINPインタラクションの30%以上がloadingまたはdom-interactiveとタグ付けされている場合、INPの問題はページの読み込み時の問題であり、JavaScriptの遅延実行が最も大きな改善をもたらします。応答性の悪いインタラクションの60%以上がcompleteとタグ付けされている場合は、実行時の問題であるため、スクリプトの読み込み順ではなく、イベントハンドラーの処理コストを最適化する必要があります。Load State（INP）ディメンションは、lab data測定セッションやカスタムの計測実装を行うことなく、1つのテーブルビューでこの判断を下すことを可能にします。