次のペイントへのインタラクションを改善する方法 (INP)

公開: 2023-07-15

Interaction to Next Paint (INP) は実験的ではなくなりました。

2024 年 3 月より、Google は、最初の入力遅延に代わる応答性の新しいコア Web Vital 指標として INP を推進することに取り組んでいます。

サイトの INP スコアの処理は後回しにしてもよい作業だと思われるかもしれませんが、私たちはそうではありません。

Google はすでに、Search Console で INP の問題にフラグを立て、良好な応答性の基準を満たしていない Web サイトにメールを送信し始めています。

Google INP 警告メール

言い換えれば、今後の応答性指標に合わせてサイトの最適化を開始するのに最適な時期は今です。 次の行で、その方法を正確に学びます。

  • 次のペイントへのインタラクションの概要
  • インタラクションのレイテンシを理解する
  • サイトが INP に失敗する理由
  • 遅いインタラクションを特定する方法
  • INPを最適化する方法

読む。


次のペイントへのインタラクション: 概要

さまざまな最適化手法を詳しく説明する前に、INP の測定内容を簡単にまとめます。

INP は、ユーザーのページ訪問中の対象となるすべてのインタラクションの待ち時間を観察することにより、ユーザー インタラクションに対するページの全体的な応答性を評価します。 最終的な INP 値は、観察された最長の相互作用です。

INP の計算に関与する相互作用は次のとおりです。

  • マウスでクリックする。
  • タッチスクリーンを備えたデバイスをタップする。
  • 物理キーボードまたはデジタル キーボードのキーを押すこと。

他の Core Web Vitals と同様に、INP スコアは次の 3 つのしきい値のいずれかになります。

  • 良い: 0-200ms
  • 改善の必要性: 200-500ms
  • 悪い: >500ms

INPしきい値

大多数のユーザーに対してこの目標を確実に達成するには、モバイル デバイスとデスクトップ デバイス間でセグメント化されたページ読み込みの 75 パーセンタイルを評価することをお勧めします。

INP についてさらに詳しく知りたい、または知識を磨きたい場合は、今後の応答性指標に関する記事をお読みください。

インタラクションのレイテンシーを理解する

INP スコアを悪い状態から良い状態にしたい場合は、インタラクションの遅延を理解する必要があります。

では、インタラクションのレイテンシとは正確には何でしょうか?

インタラクションの遅延とは、ユーザーの入力またはアクションと、その結果として画面上に表示される応答または出力との間に生じる遅延またはラグを指します。 これは、サイトの応答性と知覚されるパフォーマンスを決定する重要な要素です。

インタラクションのレイテンシーには、次の 3 つの主要なコンポーネントが影響します。

入力遅延

入力遅延とは、ユーザーがページの操作を開始してから、関連するアクションまたはイベント コールバックの実行が開始されるまでの時間を指します。 これには、入力デバイス (キーボード、マウス、タッチスクリーンなど) およびシステムの入力処理メカニズムによって引き起こされる物理的または技術的な遅延が含まれます。

処理時間

ユーザー入力を受信すると、システムはそれを処理して、適切な応答またはアクションを決定する必要があります。 処理時間とは、システムが入力データを分析および解釈し、必要な計算または操作を実行し、出力または応答を生成するのに必要な時間を指します。

プレゼンテーションの遅延

システムが出力または応答を生成した後、それがユーザーに表示されるまでには通常、遅延が生じます。 プレゼンテーション遅延には、システムがディスプレイを更新し、グラフィックスまたはユーザー インターフェイスをレンダリングし、出力をユーザー インターフェイスまたは出力デバイスに配信するのにかかる時間が含まれます。

インタラクションのレイテンシー

さらに詳しい情報が必要な場合は、JSConf Korea 2022 での Jeremy Wagner のプレゼンテーションを確認してください。


インタラクションの遅延を理解して最適化すると、シームレスなユーザー エクスペリエンスを提供し、INP スコアを修正できます。

その前に、高いインタラクション レイテンシーと悪い INP スコアの主な原因を見てみましょう…


Web サイトで Core Web Vitals INP の問題が検出されました: 何が原因でしょうか?

INP は保留中としてラベル付けされていますが、これは、戦略なしで最適化プロセスに入るべきであるという意味ではありません。

最初に行う必要があるのは、INP の主な原因が何であるかを学び、効果的に対処できるようにすることです。

「INP 問題: 200ms を超えています」エラー メッセージが表示される主な理由は次のとおりです。

長いタスク

ブラウザが行うことはすべてタスクとみなされます。 これには、レンダリング、HTML の解析、JavaScript の実行など、ユーザーが制御できるかどうかにかかわらず、あらゆるものが含まれます。

メイン スレッドは、ブラウザがページを表示するために必要な作業のほとんどを実行する場所です。 実行する必要があるタスクが数十ある場合でも、メインスレッドが一度に処理できるタスクは 1 つだけです。

メインスレッド

しかし、それは問題の半分にすぎません。

残りの半分は、タスクの実行に 50 ミリ秒を超える時間がかかる場合、そのタスクは長いタスクとして分類されます。  

メインスレッドが一度に 1 つのタスクを処理できることを考えると、タスクが長くなるほど、ブラウザーがそのタスクの処理をブロックされる時間が長くなります。

つまり、長いタスクの実行中にユーザーがページを操作しようとすると、ブラウザーがリクエストを実行するのが遅れます。

その結果、インタラクションの遅延が発生し、INP スコアが低下します。

DOM サイズが大きい

INP が失敗するもう 1 つの理由は、DOM サイズが大きいことです。

ドキュメント オブジェクト モデル (DOM) は、すべての Web ページと切り離せない部分です。 DOM は、ツリーとして構造化された HTML ドキュメントを表現したものです。 ツリー内の各枝はノードで終わり、各ノードにはオブジェクトが含まれます。 ノードは、要素、テキスト文字列、コメントなど、ドキュメントのさまざまな部分を表すことができます。

ドムの木

DOM 自体には問題はありませんが、そのサイズが問題になる可能性があります。 DOM サイズが大きいと、ブラウザーがページを迅速かつ効率的にレンダリングする能力に影響します。

DOM が大きくなるほど、ページの最初の表示と、ページのライフサイクル中のその後の更新に多くのリソースが消費されます。

簡単に言えば：

ページがユーザーの操作に迅速に応答するようにしたい場合は、DOM に必要な要素のみが含まれていることを確認してください。

「必要」とは何を意味するのか疑問に思われるかもしれません。 Lighthouse によると、ページの DOM サイズは1,400 ノードを超えると過剰になります。

したがって、必ずこの制限内に収まるようにしてください。 そうしないと、PageSpeed Insights レポートに次のエラーが表示される可能性があります。

PSI 警告 過剰な DOM サイズを避ける

クライアント側での HTML のレンダリング

クライアントサイトのレンダリングが INP スコアの低下を引き起こす理由を理解するには、それがサーバー側の HTML レンダリングとどのように異なるかを説明する必要があります。

従来のページ読み込みでは、ナビゲーションごとにブラウザがサーバーから HTML を受信します。 ユーザーがページをロードしようとすると、バックグラウンドで次のことが行われます。

  1. ブラウザは、指定された URL のナビゲーション リクエストを送信します。
  2. サーバーは HTML を分割して応答します。

ここで重要なのは「塊で」ということです。

ブラウザは HTML の最初のチャンクを受信すると、解析を開始できます。 しかし、ご存知のとおり、HTML の解析はメインスレッドが処理するタスクです。

ただし、各チャンクが処理された後、ブラウザは解析を中断し、他のタスクを実行できるようにします。 これにより、ブラウザの速度を低下させる可能性のある長時間のタスクを回避できます。

サーバーサイドレンダリング

代わりに、すでに解析されたページの部分のレンダリングを開始できるため、ユーザーには部分的に読み込まれたページがより早く表示されます。 ページの初期読み込み中に発生するユーザー操作も処理できます。

言い換えると：

このアプローチにより、ページの Interaction to Next Paint (INP) スコアが向上します。

逆に、Web サイトがシングル ページ アプリケーション (SPA) パターンを使用している場合、JavaScript を使用してクライアント上で HTML/DOM の大部分を動的に作成するため、INP スコアにマイナスの影響が生じることが予想されます。

クライアント側レンダリングでは、サーバーは基本的な HTML の小さなチャンクをクライアントに送信します。 次に、クライアントは、サーバーから取得したデータを使用して、ページのメイン コンテンツを入力します。

今後のナビゲーションはすべて JavaScript によって処理され、サーバーから新しい HTML を取得し、ページを完全に再読み込みすることなく動的に更新されます。 残念ながら、クライアント側の JavaScript タスクに関しては、自動的に分割されません。

これにより、メイン スレッドをブロックする長いタスクが発生し、ページの Interaction to Next Paint スコアに影響を与える可能性があります。 したがって、クライアント側のレンダリングは、ページの読み込みと対話性に悪影響を与える可能性があります。

サーバー側レンダリングとクライアント側レンダリングの長所と短所に関する追加情報が必要な場合は、次のビデオをご覧ください。


主な原因のいくつかがわかったので、INP スコアの測定と遅いインタラクションの特定に進みましょう。


フィールドデータを使用して遅いインタラクションを特定し、ラボでデバッグする方法

INP 最適化の次のステップは、サイトのパフォーマンスを測定し、遅いインタラクションを特定することです。

最初の入力遅延と同様に、INP は現場で測定するのが最もよく、実際のユーザーが Web サイトをどのように体験するかを調査します。

最適なテスト プロセスは次のようになります。

  1. INP用のフィールドデータを収集する
  2. INP の原因となる正確なアクションを特定する
  3. ラボツールを使用して、これらのインタラクションが遅い理由を解明する

場合によっては、サイトにフィールド データ (リアル ユーザー モニタリング (RUM) データとも呼ばれます) がない可能性があるため、最適であると述べました。 ただし、これは INP スコアの最適化を諦めるべきだという意味ではありません。 別のアプローチを採用し、利用可能なラボ ツールを活用する必要があります。

現場データと実験室データ

両方のシナリオを見て、フィールドとラボのデータの大部分を取得する方法を説明しましょう。


フィールドデータ

理想的には、サイトの応答性の向上を開始するときにフィールド データが必要になります。 RUM データに依存すると、どのインタラクションを最適化する必要があるかを判断する時間を大幅に節約できます。

さらに、ラボベースのツールは特定のインタラクションをシミュレートできますが、現実世界のユーザー エクスペリエンスを完全に再現することはできません。

INP フィールド データを収集するときは、インタラクションが遅かった理由のコンテキストを提供するために、次の情報をキャプチャする必要があります。

  • INP 値 –これらの値の分布によって、ページが INP しきい値を満たしているかどうかが決まります。
  • ページの INP を担当する要素セレクター文字列 –ページの INP 値を知っているだけでは十分ではありません。 どの要素が相互作用の原因となっているかを知りたいと考えています。
  • ページの INP であるインタラクションのページの読み込み状態 –インタラクションがページの読み込み中またはその後に発生するかどうかを理解すると、ページの初期読み込みに関係なく、メイン スレッドを最適化する必要があるのか​​、それともインタラクション自体が遅いのかを判断するのに役立ちます。
  • インタラクションの startTime –インタラクションがパフォーマンス タイムラインでいつ発生したかを知ることができるため、インタラクションの startTime を必ずログに記録してください。
  • イベント タイプ -インタラクション イベント タイプ - クリック キー押下、その他の対象となるイベントを知ることで、インタラクション内のどのイベント コールバックの実行に最も時間がかかったかを正確に特定できます。

自分自身に問いかけているなら:

これらすべてをどうやってキャプチャすればよいでしょうか?

心配しないで。 すべてのデータは web-vitals JavaScript ライブラリで公開されます。 Web-vital ライブラリを活用する方法や、INP データを Google Analytics に直接送信する方法についても、Google のステップバイステップ ガイドを確認できます。

また、すでにサードパーティの RUM プロバイダーを使用してデータを収集している場合でも、使用する手法に違いがあるため、Chrome UX レポート (CrUX) データと比較することを検討してください。

実験室データ

現場データは最も信頼できる測定源です。 ただし、前述したように、いつでも利用できるわけではありません。

ただし、ラボ データを利用して改善するためのインタラクションを測定および特定することはできるため、心配する必要はありません。

Lighthouse または PageSpeed Insights を使用して、いくつかのパフォーマンス テストを実行できます。 注目すべき指標は、合計ブロック時間 (TBT) です。

TBT は、読み込み中のページの応答性を評価する指標であり、INP と非常によく相関します。 TBT スコアが低い場合は、ページの読み込み中に速度が低下する可能性のあるインタラクションがあることを示します。

PSI での合計ブロッキング時間スコア

ラボ ツールとの遅い対話を再現する方法は次のとおりです。

  • Web Vitals Chrome 拡張機能を使用する

Web Vitals Chrome 拡張機能は、サイトのインタラクション遅延を測定する最も簡単な方法の 1 つです。 有用な情報を取得するには、次のことを行う必要があります。

  1. Chrome では、アドレス バーの右側にある拡張機能アイコンをクリックします。
  2. ドロップダウン メニューで Web Vitals 拡張機能を見つけます。
  3. 右側のアイコンをクリックして拡張機能の設定を開きます。
  4. 「オプション」をクリックします。
  5. 表示される画面で [コンソール ログ] チェックボックスをオンにし、[保存] をクリックします。

最後に、Chrome DevTools コンソールを開いてテストを開始します。 インタラクションに関する詳細な診断情報を提供する、役立つコンソール ログを受け取ります。

Chrome DevTools コンソール タブ

  • Chrome DevTools を使用してトレースを記録する

インタラクションが遅い理由についてさらに詳しい情報を得るには、Chrome DevTools のパフォーマンス プロファイラーを使用できます。 次のことを行うだけです。

  1. Chrome DevTools を開き、[パフォーマンス] パネルに移動します。
  2. パネルの左上にある「記録」ボタンをクリックしてトレースを開始します。

    Chrome DevTools の記録
  3. 必要なインタラクションを実行します。
  4. トレースを停止するには、[記録] ボタンをもう一度クリックします。

パフォーマンスの問題を迅速に特定するには、プロファイルが入力されたときにプロファイラーの上部にあるアクティビティの概要を確認します。 アクティビティの概要で、記録中の長いタスクのインスタンスを示す赤いバーを探します。 これらの赤いバーは、問題領域を特定し、調査に焦点を当てるのに役立ちます。

  • Lighthouse のタイムスパンを使用する

Lighthouse のタイムスパン モードは、DevTools パフォーマンス プロファイラーに代わる、それほど怖くない代替手段です。 使用方法は次のとおりです。

  1. DevTools の [Lighthouse] タブに移動します。
  2. 「モード」というラベルのセクションで、「タイムスパン」オプションを選択します。
  3. 「デバイス」というラベルの付いたセクションで、目的のデバイス タイプを選択します。
  4. 「カテゴリ」ラベルの下にある「パフォーマンス」というラベルのチェックボックスが少なくとも選択されていることを確認してください。
  5. [タイムスパンの開始] ボタンをクリックします。

    Chrome DevTools Lighthouse のタイムスパン
  6. ページ上で必要なインタラクションをテストします。
  7. [タイムスパンの終了] ボタンをクリックし、監査が表示されるまで待ちます。
  8. 監査が入力されたら、INP でフィルターします。

失敗した監査と合格した監査のリストが表示されます。 それらをクリックすると、ドロップダウン メニューが表示され、インタラクション中に費やされた時間を入力遅延、処理時間、プレゼンテーション遅延で割った内訳が表示されます。

監査入力に合格しました
出典: Google


何に取り組むべきかがわかったので、さあ、腕まくりして最適化を始めましょう。

INPを最適化する方法

サイトに良好なINP スコアを保証するには、各インタラクション イベントができるだけ高速に実行されるようにする必要があります。 それを達成する方法は次のとおりです。

入力遅延を軽減する

1. メインスレッドを過負荷にするタイマーの繰り返しを避ける

setTimeout と setInterval は、入力遅延の原因となる可能性がある一般的に使用される JavaScript タイマー関数です。

 setTimeout は、指定された時間の後にコールバックが実行されるようにスケジュールします。これは長時間のタスクを回避するのに役立ちますが、タイムアウトがいつ発生するか、およびそれがユーザーの操作と一致するかどうかによって異なります。

一方、 setIntervalは、指定された間隔で繰り返し実行されるコールバックをスケジュールします。 そのため、ユーザーの対話を妨げる可能性が高くなります。 その繰り返しの性質により入力遅延が増加し、インタラクションの応答性に影響を与える可能性があります。

コード内でタイマーを制御できる場合は、その必要性を評価し、可能な限りワークロードを軽減してください。

2. 長時間のタスクを避ける

すでにご存知のとおり、長いタスクはメイン スレッドをブロックし、ブラウザーがインタラクション イベントを実行できなくなります。

サイトの応答性を高めるには、メインスレッドのワークロードを最小限に抑え、長いタスクを分割することを検討することが重要です。

長いタスクを小さなチャンクに分割することで、メインスレッドは他のタスクを処理し、ユーザーの操作により迅速に応答できるようになります。

さらに、長いタスクを分割すると、メイン スレッドの過負荷によりページ上のアニメーションやトランジションが途切れたり途切れたりする「ジャンク」効果を回避するのに役立ちます。 各タスクがより短い時間枠内で完了するようにすることで、ページはユーザーにとってよりスムーズな視覚エクスペリエンスを維持できます。

長いタスクを分割する

3. インタラクションの重複を避ける

インタラクションの重複とは、訪問者が 1 つの要素とインタラクションした後、最初のインタラクションが次のフレームをレンダリングする前に、ページと別のインタラクションを行うことを意味します。

たとえば、これはユーザーがフォーム フィールドに入力しているときに発生する可能性があり、短期間に多数のキーボード操作が発生します。 次の方法でプロセスを最適化できます。

  • 入力をデバウンスして、一定期間内にイベント コールバックが実行される回数を制限します。
  • AbortController を使用して発信フェッチ要求をキャンセルし、メインスレッドがフェッチ コールバックの処理で過負荷にならないようにします。

イベントコールバック(処理時間)の最適化

1. 不要なコールバックを削除することを検討してください。

高価なイベント コールバックは本当に必要ですか? そうでない場合は、コードを完全に削除することを検討するか、それが不可能な場合は、より適切な時点まで実行を遅らせます。

キーワード: イベント コールバック
連鎖反応のようなものだと考えてください。 Web サイト上でボタンのクリックなどのアクションを実行すると、Web サイトはそのアクションをイベントとして認識します。 次に、Web サイトは、そのイベントに接続されている、コールバック関数と呼ばれる特定のコードを探します。 コールバック関数が見つかると、それが実行され、次に何が起こるかを決定します。


2. レンダリング以外の作業を延期する

長いタスクはメインスレッドに譲ることで分割できます。 メインスレッドに譲ると、基本的に現在のタスクを一時停止し、残りの作業を別のタスクに分割します。 これにより、レンダラーは、イベント コールバックで以前に処理されたユーザー インターフェイスの更新を処理できるようになります。 譲歩することで、レンダラーが保留中の変更を実行できるようになり、スムーズかつタイムリーなユーザー インターフェイスの更新が保証されます。

キーワード: 降伏
メイン スレッドを放棄するとは、メイン スレッドで実行されているタスクの実行を一時的に停止して、他のタスクが処理できるようにすることを指します。 メインスレッド上のタスクが譲歩すると、それは自発的に制御を放棄し、他の保留中のタスクの実行を許可することを意味します。 このメカニズムにより、長時間実行されるタスクがメインスレッドを独占し、ユーザー インターフェイスが応答しなくなることを防ぎます。


プレゼンテーションの遅延を最小限に抑える

1. DOM サイズを削減する

DOM サイズが大きいと、確実に INP 評価に不合格になります。 したがって、このようなことが起こらないようにするには、DOM サイズを減らす必要があります。別の言い方をすると、DOM の深さを減らす必要があります。

DOM の深さは 1,400 ノード以下を目指します。

次のテクニックを組み込むことでこれを実現できます。

  • 不適切にコーディングされたプラグインやテーマを避ける
  • JavaScript ベースの DOM ノードを最小化する
  • 肥大化した HTML を生成するページビルダーから離れる
  • WYSIWYG エディターにテキストをコピー/ペーストしないでください。
  • 1 ページの Web サイトを複数のページに分割する
  • display:none を使用して不要な要素を非表示にしないでください
  • 複雑な CSS 宣言と JavaScript の使用を避ける

2. requestAnimationFrame コールバックでの過剰または不必要な作業を避ける

requestAnimationFrameメソッドは、ブラウザにアニメーションを実行したいことを伝え、ブラウザが次の再描画の直前に指定された関数を呼び出してアニメーションを更新するように要求します。

requestAnimationFrame() コールバックはイベント ループのレンダリング フェーズの一部であり、次のフレームが表示される前に終了する必要があります。 ユーザー インターフェイスの変更に関係のないタスクに requestAnimationFrame() を利用している場合は、後続のフレームのレンダリングに遅延が発生している可能性があることを認識することが重要です。

したがって、不必要な場合は使用を避けてください。

3. ResizeObserver コールバックを延期する

ResizeObserver インターフェイスは、要素のコンテンツ、境界ボックス、または SVGElement の境界ボックスの寸法の変更を報告します。

ResizeObserver コールバックはレンダリング前に実行されるため、リソースを大量に消費するタスクが含まれる場合、次のフレームのプレゼンテーションが延期される可能性があります。 イベント コールバックと同様に、すぐに来るフレームに必要のない不要なロジックは延期することをお勧めします。


NitroPack で INP を向上させる

過去 2 か月間に実行したすべてのテストと、Google が INP で公開したすべてのドキュメントに基づくと、これは Largest Contentful Paint (LCP) によく似ていると言えます。

多くの可動部分を備えた多層構造の Core Web Vital。

そのため、Google が最初に新しい応答性指標を発表して以来、クライアントの INP スコアを向上させる機能のテストと取り組みを開始しました。

そして、いくつかの有望な結果が得られています。

NitroPack を使用すると、当社のお客様は INP が平均 36% 向上することを実感しています。

そしてそれはすべて自動操縦で起こりました。 NitroPack をインストールするだけで、次のような最適化機能のおかげで:

  • 使用しないCSSを減らす
  • JavaScriptの読み込みを延期する
  • 内蔵CDN

コードを 1 行も記述せずに、INP スコアと Core Web Vitals スコアを向上させることもできます。 NitroPack を無料でインストールして、改善点をご自身で体験してください。

INP の問題を修正し、Core Web Vitals を自動的に渡します。 今すぐニトロパックを入手 →