Interaction to Next Paint (INP) の問題を見つけて修正する

Interaction to Next Paint (INP) の問題を見つけて修正する

前回の記事では、Interaction to Next Paint について説明しました。基本について学びたい方は、こちらから始めるのがおすすめです！

この記事では、さまざまな Interaction To Next Paint の問題の特定に焦点を当て、その修正方法を解説します！

INP のヒント：ほとんどの場合、ページ読み込みの起動段階でユーザーがページを操作すると、INP は大幅に悪化します。そのため、INP をデバッグする際は、すべてのインタラクションとページの読み込み状態をログに記録することが理にかなっています！

ステップ1：Search Console で INP を確認する

「回復への第一歩は、問題があることを認めることです」。Interaction to Next Paint を修正する前に、本当に Interaction to Next Paint に問題があるか確認しましょう。

Google Search Console にログインしてください。左メニューの Core Web Vitals をクリックし、モバイルまたはデスクトップを選択します（ヒント：ほとんどの場合、INP の問題はモバイルで発生するため、モバイルから始めてください）

ここでは、サイトに現在存在するすべての Core Web Vitals 関連の問題の概要が表示されます。これらの問題のいずれかが INP に関連している場合、問題があることが確認できます！

ステップ2：Interaction to Next Paint の問題を特定する

Google Search Console では、Interaction to Next Paint の問題の原因を特定するための情報として、URL グループ以外の情報は提供されません。そのため、ほとんどの開発者は闇雲に作業を始めてしまいます。未使用の JavaScript の削除（常に良いアイデアです）やメインスレッドの分割（これも良いアイデアです）を始めますが、INP を完全に修正できることはほとんどありません。

そのため、INP を改善する際は、何が起きているかを正確に把握する必要があります。

どの要素が操作されたときに悪い INP スコアを引き起こすか。通常、悪い INP スコアは単一の要素ではなく、複数の問題の組み合わせによって引き起こされます。最悪のものから順に、一つずつ対処していく必要があります。
これらのインタラクションはいつ発生するか？ページ読み込みの起動段階で発生するのか、メインページの読み込みが完了した後でも発生するのか。
これらのインタラクションはどこで発生するか？すべてのページで発生するのか、特定の数ページでのみ発生するのか。
これらのインタラクションをどのように再現できるか？ INP の問題を再現するのが難しいことにお気づきかもしれません。そのため、悪い INP スコアを示すデバイス特性を模倣することで、成功に向けた準備をする必要があります。

RUM トラッキングを設定する

これらすべての質問に答えるためには、実際のユーザーのトラッキングを開始し、Interaction to Next Paint で発生する可能性のある問題をログに記録する必要があります。RUM トラッキングを有効にする方法はいくつかあります。1つ目は、Web Vitals ライブラリを活用し、結果を独自のアナリティクスバックエンドに送信する方法です。この方法の利点は、安価で柔軟性があることです。欠点は、追加作業が多くなる可能性があることです。

Core Web Vitals データを独自のバックエンドに送信する代わりの良い方法は、多数ある RUM ツールの1つを使用することです。私たちはこのようなユースケースのために CoreDash を開発しました。CoreDash は低コストで高速かつ効果的な RUM ツールで、確実に仕事をこなします！もちろん、他にも多くの RUM ソリューションがあり、それらも同様に機能します（ただし、より高価です）

高い INP を引き起こす要素ごとの遅いインタラクションを見つける

最初にすべきことは、最悪の Time to First Byte スコアを引き起こす「最も遅い」インタラクションを見つけることです。CoreDash で「要素別 INP メトリクス」でページを一覧表示するだけで、最も遅いインタラクションが表示されます。最初の行をクリックして、これらのインタラクションでメトリクスをフィルタリングしてください。

悪い INP インタラクションがいつ発生するかを見つける

次に、フィルタリングされた URL をロード状態でソートします。これにより、INP の根本原因についてより深い洞察が得られます。この場合、高い INP は DOM コンテンツが読み込まれた時点で発生しています。つまり、スクリプトは解析されましたが、非同期スクリプトとページのサブリソースはまだ読み込まれていません。この場合、INP はページの読み込みが完全に完了する前の早期クリックによって引き起こされています！

最も影響の大きいロード状態をクリックして、別のフィルターを作成してください！

高い INP スコアの原因となる URL を見つける

最後に、最も遅いインタラクションの要素と正しいロード状態でフィルタリングした後、INP が最悪の URL を確認します。この場合、特定のページセットで明らかに発生しています。

デバイス特性を見つける

最後に、遅いインタラクション、ロード状態、高い Interaction to Next Paint を引き起こす URL を特定したら、最悪の INP スコアを引き起こす訪問者のタイプを確認します。デバイスメモリ、帯域幅、画面サイズなどを確認します。これらの特性を特定したら、問題の再現とログ記録に進みます！

ステップ3：高い INP スコアを引き起こすインタラクションを再現してデバッグする

必要なすべての情報が揃ったら、Interaction to Next Paint の根本的な問題を深く掘り下げることができます。

成功に向けた準備：INP が失敗する状況を再現する

次にすべきことは、失敗する INP を再現することです。INP が失敗する可能性のある状況を模倣することでこれを行います。

Chrome パフォーマンスパネルを使用します：Chrome デベロッパーツール（Ctrl-Shift-i）を開き、パフォーマンスパネルを選択します。上部バーで CPU スロットリング（通常のモバイルデバイスをエミュレートするために4倍のスローダウンに設定）、ネットワークスロットリング（平均的なモバイルデバイスを模倣するために Fast 3G プリセットを選択）を選択し、ハードウェア並行性を4または8に設定して平均的なモバイルを模倣します。

利用可能なメモリを少なくして Chrome を読み込むには（ネットワークと CPU の設定を下げるだけで十分な場合が多いですが！）、Docker コンテナで Chrome を起動し、メモリを少なく割り当ててください。

ページをリロードし、操作して、Core Web Vitals ビジュアライザーで INP を確認する

悪い INP スコアの原因を見つける次のステップは、条件をシミュレートし、INP スコアが報告どおりに悪いことを確認することです。

ページをリロードして、適切なタイミングで適切な要素をクリックしてください

パフォーマンストレースで INP をデバッグする

これは、前のステップで準備してきた瞬間です。特定のインタラクションが悪い Interaction To Next Paint スコアを引き起こしている理由を見つける時です。

Chrome デベロッパーコンソール（Ctrl-Shift-i）を再度開き、パフォーマンスパネルに移動し、今度は円形の矢印アイコンをクリックしてページをリロードし、記録を開始します（または Ctrl-Shift-E ショートカットを使用します）。

Chrome デベロッパーコンソール（Ctrl-Shift-i）を再度開き、パフォーマンスパネルに移動し、今度は円形の矢印アイコンをクリックしてページをリロードし、記録を開始します（または Ctrl-Shift-E ショートカットを使用します）。

ステップ3：INP の問題を修正する

どのインタラクションが悪い INP を引き起こしているかを把握し、この遅いインタラクション中に何が起きているかを正確に分析できた段階まで来ました。つまり、Interaction to Next Paint の修正を開始する時です。Interaction to Next Paint は3つのフェーズに分解できます：「input delay」、「processing time」、「presentation delay」です。

Interaction to Next Paint の各フェーズは、それぞれ異なる方法で対処する必要があります！

Input Delay を最小化する：

Input delay は、ページとのインタラクションからイベントコールバックの実行開始までの時間です。常にある程度の input delay は存在しますが（ブラウザもコールバックのスケジューリングに時間が必要です）、いくつか考慮すべき点があります：

1. 長いタスクを避ける。タスクが実行されるたびにメインスレッドがブロックされ、イベントコールバックが待機状態になります。これは、早期クリックの最適化時に特に重要です（その時点でほとんどのスクリプトが実行されているため）。 
2. 新しいタスクの作成に注意する。例えば、setTimeout() による定期的なタスクや、mouseover イベントのコールバックなど、INP イベントの前に発生する可能性が高いタスクです。
3. 早期インタラクションを測定・評価する。インタラクティブな要素が早期に表示され（例えばサイト検索要素）、後から読み込まれる JavaScript によって制御される場合、その要素とのインタラクションは即座のレイアウト更新をトリガーしません。機能を優先するか、適切に動作する前に要素を非表示/無効にしてください。
4. Web Workers を使用して JavaScript をブラウザのメインスレッド外で実行する。Web Workers を使用すると、スクリプトをメインスレッド外で実行できます。これにより、メインスレッドのブロックを防ぎ、INP の input delay の問題を回避できます。
   
5. あると便利なサードパーティスクリプトはブラウザのアイドル時間に読み込む。 スクリプトの中には他より重要なものがあります。これらのスクリプトを優先し、重要度の低いスクリプトはブラウザのアイドル時間に読み込むことが合理的です。例えばチャットスクリプトなどです。

Processing time を最小化する

1. 不要なコードを削除する。不要なコードとは、まだ実行されている古いコード、またはこの特定のページでは不要なのに CPU 時間を消費している新しいコードです。これは INP を即座に改善する最も簡単な方法です。
2. 次のペイントの前に実行する必要のないコードを遅延させる。コードを、INP の前に実行する必要があるクリティカルなコードと、ノンクリティカルなコード（例えばアナリティクスの送信）に分割し、requestIdleCallback() メソッドを使用して INP イベントの後にスケジューリングします。 
3. ペイントの前に実行する必要があるコードを最適化する。コードを確認し、遅い部分や非効率な部分を書き直してください。
4. 即座のフィードバックを提供する。複雑または遅くなる可能性のあるタスクでは、メインコードを実行する前に即座のフィードバックを提供してください。

Presentation Delay を最小化する

1.  DOM を小さくシンプルに保つ。基本的に、少数のシンプルでネストされていない DOM 要素（HTML ノード）のページをレンダリングする方が、多数のネストされた DOM ノードを持つページをレンダリングするよりもはるかに簡単です。
   
2. content-visibility を使用して画面外のコンテンツを遅延レンダリングする。 content-visibility は、画面外のコンテンツのレンダリングをジャストインタイムで遅延させることにより、ページの表示部分のレンダリングを高速化します。