Core/Dash Dimension: Load State (INP)

ディメンション: Load State INP (inpls)

Load State (INP)ディメンションは、ユーザーインタラクションがキャプチャされた正確な瞬間のドキュメントの準備状態を記録します。Chrome User Experience Reportの各INPイベントには、loading、dom-interactive、dom-content-loaded、completeのいずれかのロードステートタグが付与されています。CoreDashはそのタグをフィルタリング・グループ化可能なディメンションとして表示するため、生のINPスコアでは答えられない質問に回答できます：ページライフサイクルのどの時点で最悪のインタラクションが発生したのか？

この質問は、まったく異なる2つのエンジニアリング修正の分岐点です。loading中に集中するINP問題にはJavaScriptの遅延読み込み戦略が必要です。complete中に集中するINP問題には、イベントハンドラーの作業の削減、フレームワークのオーバーヘッドの軽減、またはランタイムコード内のロングタスクの分割が必要です。ロードステートによるグループ化により、手動の計測なしでその分類が可能になります。

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

スクリーンショット

Load StateがINPにとって重要な理由

Interaction to Next Paintメトリクスは、ユーザーインタラクションの全レイテンシを測定します：入力遅延、イベントハンドラーの処理時間、次のペイントフレームまでのプレゼンテーション遅延。これら3つのコンポーネントのうち、入力遅延はユーザーがクリックまたはタップした瞬間にブラウザが何をしているかによって最も直接的に制御されるものです。

ページ読み込みの初期段階では、メインスレッドは最大限の競合状態にあります。ブラウザはHTMLを解析し、同期スクリプトを実行し、CSSOMを構築し、パーサーブロッキングリソースを実行し、レンダリングサイクルを連続して実行しています。メインスレッド上のすべてのロングタスクは、ユーザーインタラクションがキューに入れられ待機するウィンドウとなります。その待機が入力遅延であり、ページ読み込み中のINP悪化の主要な要因です。

document.readyStateがcompleteに達した後に到着するインタラクションは、より静かなメインスレッドに直面します。ブラウザはロードを完了しています。この段階でまだINPが悪い場合、原因はローディングの競合ではありません。ユーザーアクションに応じてページが実行するJavaScript、つまり肥大化したイベントハンドラー、フレームワークの再レンダリングサイクル、スクリプトによってトリガーされるレイアウトスラッシング、またはインタラクション中に同期的に実行される最適化されていないサードパーティコードが原因です。

ロードステートは、これら2つの根本原因を分離するための最も迅速なフィルターです。

ロードステート

loading

ページはHTMLドキュメントの解析を完了していません。メインスレッドは同期スクリプトを実行し、パーサーブロッキングリソースをフェッチし、初期DOMを構築しています。これはユーザーインタラクションにとって最も厳しい環境です。すべてのロングタスクがブラウザのクリックやタップの処理を直接ブロックするため、入力遅延は最大になります。このウィンドウ中にインタラクションするユーザーは、通常最もせっかちな訪問者か、ページの読み込みが完了する前に表示コンテンツに到達した高速接続のユーザーです。彼らのINPスコアは収集する中で最悪のものになります。悪いINPイベントのかなりの部分がloadingステートを持つ場合は、非クリティカルなスクリプトをdeferまたはasyncに移動し、ファーストビュー上のパーサーブロッキングリソースを排除してください。

dom-interactive

document.readyStateは、HTMLが完全に解析されDOMが構築されたが、画像、スタイルシート、遅延スクリプトなどのサブリソースがまだ読み込み中のときにinteractiveに到達します。この時点で遅延スクリプトの実行が開始されるため、メインスレッドはまだ大きく占有されている可能性があります。フレームワークのハイドレーションは多くの場合ここから始まります。ページはユーザーにとって準備完了に見えますが、メインスレッドはまだ忙しいため、これは危険なウィンドウです。入力遅延は引き続き高い状態です。悪いINPがここに集中している場合、修正はloadingと同じです：DOM解析完了直後に実行される同期作業の量を削減してください。

dom-content-loaded

DOMContentLoadedイベントが発火しました。DOMは完成し、遅延スクリプトは実行済みです。ほとんどのJavaScriptフレームワークはこの時点で初期ハイドレーションパスを完了しています。メインスレッドのワークロードは減少し、インタラクションはより速い応答を得始めます。このステート中のINPスコアは、前の2つのステートよりも通常は良好ですが、completeと比較するとまだ高い状態です。ここで悪いインタラクションの集中が見られる場合は、フレームワークやアプリケーションスクリプトがDOMContentLoadedハンドラーで何をしているか、ハイドレーション作業をチャンク化またはyieldしてタスク間で入力処理を許可できるかを調べてください。

complete

document.readyStateは、画像、フォント、サードパーティのiframeを含むすべてのリソースが読み込まれたときにcompleteに到達します。これはセッションの残りの間ページが動作する定常状態です。このステートでのINPの悪化は純粋なランタイムの問題です。ページはロードを完了しています。メインスレッドがまだインタラクションをブロックしている場合、原因はインタラクション中のJavaScript実行にあります：同期作業が多すぎるイベントハンドラー、コストの高いレイアウト再計算をトリガーするフレームワークの更新、またはインタラクション中に継続的にロングタスクを実行するサードパーティスクリプト。修正は遅延読み込みについてではありません。ユーザーが実際にクリックしたときに発生する処理のコストを削減することです。

デバッグワークフロー

ステップ1：CoreDashでロードステートでフィルタリング。 INPブレークダウンテーブルを開き、Load Stateでグループ化します。どのステートが悪い（200msを超える）インタラクションの最大のシェアを占めているかを特定します。これにより、ローディングの問題なのかランタイムの問題なのかが即座にわかります。

ステップ2：URLとデバイスとのクロスリファレンス。 Load Stateディメンションとアカウントディメンションを組み合わせて、初期ロードステート中に悪いインタラクションを生成する特定のページを見つけます。モバイルデバイスは、CPUが遅いためすべてのロングタスクが長くなるため、ローディング中に不均衡な影響を受けます。

ステップ3：ステートに合った修正を適用。 loadingとdom-interactiveについては、INP最適化ガイドを使用してスクリプト読み込み戦略を監査します。スクリプトをdeferに移動し、レンダーブロッキングリソースを排除し、scheduler.yield()を使用して長い初期化タスクを分割します。completeについては、Chrome DevToolsでイベントハンドラーをプロファイリングし、インタラクションごとにトリガーされる同期作業を削減します。

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

悪いINPインタラクションの30%以上がloadingまたはdom-interactiveとタグ付けされている場合、INPの問題はページロードの問題であり、JavaScriptの遅延読み込みが最大の改善をもたらします。悪いインタラクションの60%以上がcompleteとタグ付けされている場合、INPの問題はランタイムの問題であり、スクリプトの読み込み順序ではなく、イベントハンドラーのコストを最適化する必要があります。Load State (INP)は、ラボセッションやカスタム計測を必要とせず、1つのテーブルビューでその判断を可能にします。