Interaction to Next Paint (INP): とは何か、測定および改善方法

Interaction to Next Paint (INP) は、クリック、タップ、キー入力といったユーザーの操作に対してウェブページがどれだけ迅速に応答するかを測定する Core Web Vitals 指標です。INPは、ユーザーの入力から JavaScript の処理を経て、最終的に画面上の視覚的な更新が行われるまでのすべてのレイテンシをキャプチャします。75パーセンタイルにおいて200ミリ秒以下であれば、良好なINPスコアとみなされます。INPは2024年3月にFirst Input Delay (FID) に代わって Core Web Vitals になりました。

Interaction to Next Paint (INP) とは？

Interaction to Next Paint (INP) は、ユーザーの訪問全体にわたるウェブページの応答性を測定する Core Web Vitals の指標です。最初のインタラクションのイベントハンドラが開始されるまでの遅延のみを測定していた以前の指標である First Input Delay (FID) とは異なり、INPはユーザーがページで行うすべてのインタラクションを評価し、ページ全体の応答性を表す単一の値を報告します。

ユーザーがボタンをクリックしたり、リンクをタップしたり、キーボードのキーを押したり、カスタムコントロールを操作したりするたびに、ブラウザは入力された瞬間から次のフレームが画面に描画されるまでの合計時間を測定します。INPは、ページの応答性スコアとして、これらのインタラクションの中で最も遅いものの1つを選択します。合計インタラクションが50回未満のページの場合、INPは最も遅かった1回のインタラクションを報告します。インタラクションが多いページの場合、INPは通常、まれな外れ値を除外するために98パーセンタイルの値を使用します。

低いINPは、ページがユーザーの入力にタイムリーに、そして確実に応答していることを意味します。高いINPは、ブラウザがインタラクションを処理して画面を十分に速く更新できないため、ページがもたついていたり、応答していなかったり、あるいは「カクついている」と感じられることを意味します。

INP と FID の比較: 何が変わり、なぜ変わったのか

INPは、2024年3月に公式にFirst Input Delay (FID) に代わる Core Web Vitals となりました。GoogleがFIDを廃止した理由は、FIDにはページの応答性の測定として不完全となる2つの根本的な限界があったためです。

第一に、FIDはページ上の最初のインタラクションのみを測定していました。ユーザーの最初のクリックが高速でも、その後のインタラクションが遅い場合、FIDは不十分な UX にもかかわらず合格スコアを報告してしまっていました。INPはセッション全体にわたるすべてのインタラクションを測定し、実際の応答性のより正確な状況を提供します。

第二に、FIDは入力遅延フェーズのみを測定していました。つまり、イベントの処理を開始する前にブラウザが待機していた時間のみをキャプチャしていました。イベントハンドラのコードの実行に費やされた時間 (処理時間) や、画面上に視覚的な結果を描画するのに必要な時間 (表示遅延) は完全に無視されていました。INPは3つのフェーズすべてをキャプチャし、開発者にインタラクションのレイテンシの完全なビューを提供します。

HTTP Archive の 2025 Web Almanac によると、FIDからINPへの移行により、モバイルの Core Web Vitals 合格率が約5パーセントポイント低下しました。これは、FIDの基準では応答性が高いと見なされていた多くのサイトで、その後に遅いインタラクションが発生しており、それが現在はINPによって捕捉されるようになったためです。

INP はどのインタラクションを測定するのか？

INPは、ブラウザがイベントハンドラを通じて監視できる、個別のユーザー入力が関与するインタラクションのみを測定します。どのインタラクションがカウントされるかを理解することは、正確なデバッグと最適化に不可欠です。

INP の対象となるインタラクション

• マウスクリック (ボタン、リンク、チェックボックス、カスタムコントロールのクリックを含む)
• タッチスクリーンでのタップ (モバイルデバイスでのクリックに相当)
• 物理的または画面上のキーボードでのキー入力 (フォームフィールドへの入力、Enterキーの押下、キーボードショートカットの使用を含む)

INP の対象とならないインタラクション

• スクロールは、ブラウザのコンポジタスレッドで処理され、通常はメインスレッドをブロックしないため、カウントされません。
• ホバー (マウスオーバー) は、ホバーが連続的なポインタ状態であり、個別のユーザーインタラクションではないため、カウントされません。
• ドラッグジェスチャはカウントされませんが、ドラッグを開始する最初の pointerdown はINPエントリをトリガーする可能性があります。
• ユーザー入力なしで発生するCSS トランジションとアニメーションは、インタラクションではありません。

スクロールがINPに影響するというのが一般的な誤解です。影響しません。ただし、ネイティブのブラウザスクロールの代わりに JavaScript ベースのスクロール を使用している場合、それらの JavaScript のスクロールハンドラが、ブラウザによってインタラクションとして測定されるイベントコールバックをトリガーする可能性があります。これが、ネイティブの CSS スクロールが応答性の点で一貫して JavaScript のスクロールを上回る理由の1つです。

INP インタラクションの3つのフェーズ

INPによって測定されるすべてのインタラクションは、3つの連続するフェーズで構成されています。合計のINP値はこれら3つの合計です。各フェーズで最適化戦略が異なるため、それぞれを理解することが重要です。

1. 入力遅延 (Input Delay)

入力遅延は、ユーザーがページを操作してから、ブラウザが関連するイベントハンドラの実行を開始するまでの時間です。この遅延は、ブラウザのメインスレッドが、JavaScript の解析、以前にスケジュールされたタスクの実行、または他のイベントコールバックの処理などの他の作業でビジー状態になっている可能性があるために発生します。

入力遅延は、多くのスクリプトが同時に解析され実行されているページ読み込みフェーズで特に問題となります。CoreDash のデータによると、読み込みフェーズ中のインタラクションは75パーセンタイルのINPが132msであるのに対し、ページ読み込み完了後のインタラクションはわずか50msです。これは2.6倍の違いです。ページの起動時にメインスレッドの競合を減らすことは、INPを改善するための最も効果的な方法の1つです。

中央値において、入力遅延はINPのサブパートの中で最も小さいものです。しかし90パーセンタイルにおいて、メインスレッド上の長いタスクがイベント処理を数百ミリ秒も遅延させる可能性があるため、入力遅延は主な要因となります。HTTP Archive の 2025 Web Almanac によると、タスクの期間を推奨される50msのしきい値未満に保っているウェブサイトは25%未満でした。

2. 処理時間 (Processing Time)

処理時間は、インタラクションに関連するすべてのイベントハンドラのコールバックの実行にブラウザが費やす合計時間です。これには、フォームの検証、状態の更新、分析のトラッキング呼び出しなど、イベントに応答して実行されるすべての JavaScript が含まれます。

処理時間は合計INPの大部分を占めます。イベントハンドラが高コストな DOM 操作を実行したり、同期API呼び出しを行ったり、非効率なループを実行したりすると、処理時間は膨れ上がります。処理時間を増加させる一般的なパターンの1つは、重要でないコード (アナリティクスのイベントやサードパーティのタグコールバックなど) を、重要な視覚的更新と同じイベントハンドラ内で実行することです。

3. 表示遅延 (Presentation Delay)

表示遅延は、すべてのイベントハンドラの実行が完了してから、ブラウザが視覚的な更新を含む次のフレームを表示するまでの時間です。このフェーズには、スタイルの再計算、レイアウトの計算、ペイント、およびコンポジットが含まれます。

すべてのインタラクションには少なくとも1回のレンダリングパスが必要なため、中央値において、表示遅延はINPのサブパートの中で最大です。DOM サイズが大きかったり、深くネストされているページは、スタイルの再計算とレイアウトの実行に時間がかかります。状態の変更後に大規模なコンポーネントツリーを再レンダリングするシングルページアプリケーション (SPA) は、特に表示遅延が大きくなりやすい傾向があります。

良い INP スコアと悪い INP スコアとは？

Interaction to Next Paint 指標の Core Web Vitals 評価に合格するには、フィールドで記録されたすべてのインタラクションの75パーセンタイルが200ミリ秒未満にとどまる必要があります。

• INP が 200ミリ秒以下 の場合、ページの応答性は良好であることを意味します。
• INP が 200〜500ミリ秒 の場合、ページの応答性は改善が必要であることを意味します。
• INP が 500ミリ秒を超える 場合、ページの応答性は不良であることを意味します。

INPでは平均値ではなく、75パーセンタイルを使用していることを理解することが重要です。これは、実際のユーザーの75%が200ms未満の高速なインタラクションを経験しなければならないことを意味します。75パーセンタイルの手法により、この指標がハイエンドなハードウェアを使用しているユーザーだけでなく、低速なデバイスや接続環境での UX も反映することが保証されます。

Interaction to Next Paint (INP) の測定方法

Interaction to Next Paint は、実際のユーザーのインタラクションをキャプチャするフィールドツールでのみ測定できます。1回のページ読み込みをシミュレートするラボ環境の指標とは異なり、INPでは実際の訪問者がページをクリック、タップ、入力する必要があります。INPは実際の人間行動に依存しているため、合成テストから意味のあるINPスコアを取得する方法はありません。

公式の INP 指標を取得する

公式のINP指標は、PageSpeed Insights、または CrUXダッシュボードと Google BigQuery から取得できます。PageSpeed Insights は、過去28日間の Chrome ユーザーデータに基づいた75パーセンタイルのスコアを報告します。Google BigQueryは、より多くの履歴コンテキストを提供し、CrUXデータセット全体に対するカスタムクエリを可能にします。

Google Search Console も、Core Web Vitals セクションでINPの課題を報告し、影響を受けたURLをグループ化し、改善が必要なページや応答性が低いページをフラグ付けします。

Real User Monitoring を使用して INP を追跡する

公式のCrUXデータセットは Core Web Vitals スコアの決定的な情報源ですが、高度に匿名化されており、リアルタイムのモニタリングや詳細なフィルタリングはサポートされていません。そのため、ウェブパフォーマンスの専門家は、実用的でリアルタイムなINPデータを取得するために、CoreDash のような RUM ツールに依存しています。RUM ツールは、すべてのページ読み込みからINP測定値を収集し、それを特定の要素、読み込み状態、およびデバイスタイプに属性付けし、どのインタラクションが問題を引き起こしているかを正確に診断できるようにします。

現在のセッションの INP を測定する

開発中にINPをデバッグする最も簡単な方法は、Chrome DevToolsを使用することです。「パフォーマンス (Performance)」パネルを開き、Lighthouse の「タイムスパン (timespan)」モードを使用してインタラクションを記録し、そのレイテンシを確認します。また、ページを操作しているときにINPスコアをオーバーレイ表示する Core Web Vitals Visualizer 拡張機能を使用することもできます。

実践的なデバッグには、Googleの Web Vitals JavaScript Library を使用して、個々のインタラクションをコンソールにログ記録します。

Web Vitals JavaScript ライブラリを使用して INP をコンソールにログ記録する

<script type="module">
 import {onINP}
 from 'https://unpkg.com/web-vitals@4/dist/web-vitals.attribution.js?module';
 onINP(console.log);
</script>

Interaction to Next Paint の改善方法

Interaction to Next Paint を改善するには、入力遅延、処理時間、および表示遅延の3つのフェーズすべてを最適化する必要があります。ページがほとんどのインタラクションに瞬時に応答したとしても、1つのインタラクションが遅いだけで、それが全体のINPスコアを決定づけてしまう可能性があります。だからこそ、体系的なアプローチが必要です。

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

1. 入力遅延の最小化: メインスレッドでの長いタスクを防ぐ

通常、どのページも、メインスレッドの作業 (解析、デコード、レンダリング、スクリプト実行) の大部分が行われるページの起動フェーズ中は応答性が低下します。メインスレッドをできるだけ空けておくために、次のようにします。

• 未使用のコードを削除する。 ツリーシェイキングを使用してデッドコードを取り除き、コードスプリッティングを使用してバンドルをオンデマンドで読み込まれる小さなチャンクに分割します。Chrome DevTools を使用してコードカバレッジを監査し、読み込まれても実行されないスクリプトを特定します。
• ブラウザのアイドル時間に重要でないコードを読み込む。 ページ読み込みの最初の500ミリ秒の間に、チャットウィジェット は本当に必要でしょうか？ ブラウザがアイドル状態のときにのみ実行されるように、requestIdleCallback() を使用して重要でないスクリプトをスケジュールします。
• 過剰なCPUリソースを消費する遅いスクリプトを特定し、書き直す。Chromeのパフォーマンスパネルを使用して実行時間の長いスクリプトを見つけ、最適化の対象とします。
• ページをレンダリングしやすく保つ。 大規模な DOM サイズ、過剰な画像、多すぎる動画、およびCPU負荷の高い CSS アニメーションを避けます。
• JavaScript が HTML パーサーをブロックするのを防ぐために、スクリプトタグに async と defer を使用する。ページがインタラクティブになるまで、重要でない JavaScript を完全に遅延 (defer) させる ことを検討してください。

scheduler.yield() で長いタスクを分割する

JavaScript は、「実行完了 (run to completion)」モデルを使用してブラウザのメインスレッドで実行されます。つまり、タスクが開始されると、完了するまでメインスレッドをブロックします。(50msを超える) 長いタスクは、ブラウザがユーザー入力に応答するのを妨げます。scheduler.yield() APIを使用すると、実行時間の長いコード内に yield ポイントを明示的に作成でき、ブラウザが保留中のユーザーインタラクションを処理してから続行する機会を与えられます。

async function yieldToMain() {
  if ('scheduler' in window && 'yield' in window.scheduler) {
    return await window.scheduler.yield();
  }
  // scheduler.yield() のないブラウザ向けのフォールバック (fallback)
  return new Promise((resolve) => {
    setTimeout(resolve, 0);
  });
}

// 使用法: 長いタスクを小さなチャンクに分割する
async function processLargeDataSet(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);

    // 5アイテムごとに yield し、ブラウザにユーザー入力を処理させる
    if (i % 5 === 0) {
      await yieldToMain();
    }
  }
}

requestIdleCallback で重要でない作業を遅延させる

requestIdleCallback() を使用して、重要でないタスク (アナリティクス、テレメトリー、プリフェッチ) をブラウザがアイドル状態のときにスケジュールします。これにより、メインスレッドがユーザーインタラクションのためにクリアに保たれ、入力遅延が直接的に軽減されます。

// アナリティクスを同期的に実行する代わり:
document.querySelector('.cta-button').addEventListener('click', (e) => {
  // 必須: UIを即座に更新する
  showConfirmation();

  // 重要ではない: アイドル時間にアナリティクスを送信する
  requestIdleCallback(() => {
    sendAnalyticsEvent('cta_clicked', { page: location.pathname });
  }, { timeout: 2000 });
});

パッシブイベントリスナーを使用する

preventDefault() を呼び出す必要がないイベントの場合、イベントリスナーを passive としてマークします。これにより、ブラウザはハンドラがデフォルトの動作をキャンセルするかどうかを決定するのを待つ必要がないことがブラウザに伝わり、スムーズなスクロールと高速なタッチ応答が可能になります。

// パッシブリスナー: ブラウザは preventDefault() を待ちません
document.addEventListener('touchstart', handleTouch, { passive: true });
document.addEventListener('wheel', handleWheel, { passive: true });

2. 処理時間の最小化: 即時のフィードバックを提供する

訪問者がフォームを送信したり、アイテムをバスケットに追加したりするアクションを実行したときに、UIを更新する前にサーバー側の確認を待たないでください。「フォームを送信しています...」、「アイテムをバスケットに追加しています...」といった即時の視覚的フィードバックを提供し、バックグラウンドで操作を完了させます。

また、重要な視覚的な更新の後は、できるだけ早くメインスレッドを yield します。JavaScript は「実行完了 (run to completion)」モデルに従うため、コールバック内のすべてのコードが実行されるまでメインスレッドをブロックします。ブラウザがレイアウトを更新し、その後残りの重要でないコードの実行を継続できるような yield ポイントを手動で作成できます。

const formfeedbackEl = document.getElementById("formfeedback");
const formEl = document.getElementById("form");

formEl.addEventListener("submit", (evt) => {
  evt.preventDefault();
  formfeedbackEl.innerText = "フォームを送信しています... そのままお待ちください";

  let headers = new Headers({ Accept: "application/json" });
  let formData = new FormData(formEl);
  fetch("/form-endpoint", { method: "POST", headers, body: formData })
    .then(function (response) {
      return response.json();
    })
    .then(function (jsonData) {
      formEl.reset();
      formfeedbackEl.innerText = jsonData.message;
    });
   setTimeout(other_code_that_needs_to_run(), 0);
});

3. 表示遅延の最小化: シンプルに保つ

インタラクションの後にページを更新する必要がある場合、ブラウザはスタイルの再計算、レイアウトの実行、変更されたピクセルのペイント、および結果のコンポジットを行う必要があります。DOM の複雑さとサイズは、このレンダリング作業にかかる時間を直接決定します。

最適化が不十分な一部のSPA環境では、各インタラクションの後に過剰なコンテンツを再レンダリングします。例えば、カウンターを更新する場合、コンポーネントツリー全体ではなく、カウンター要素のみを更新するようにしてください。

レンダリングを高速化するために、次の2つの黄金律に従います。

1. DOM を小さくシンプルに保つ。 ブラウザにとって、深くネストされた複雑な DOM 構造を持つページよりも、DOM 要素 (HTMLノード) が少ないページをレンダリングする方がはるかに簡単です。合計 DOM 要素数を1,400未満に抑えることを目指し、32レベルを超えるネストを避けてください。
2. content-visibility を使用して、画面外のコンテンツを遅延レンダリングする。 content-visibility: auto CSS プロパティは、ユーザーがその近くにスクロールするまで画面外のコンテンツのレンダリングを遅延させることで、初期レンダリングを高速化します。

/* 画面外のセクションに content-visibility を適用する */
.below-the-fold {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px;
}

Long Animation Frames (LoAF) API を使用した INP のデバッグ

Long Animation Frames (LoAF) API は、INPの問題を診断するための強力なツールです。これには、レンダリングに50ms以上かかるフレームに関する詳細な情報が提供され、どのスクリプトが遅いインタラクションの一因となっているかを正確に伝えるスクリプト属性データも含まれます。

古い Long Tasks API とは異なり、LoAFはレンダリング時間とスクリプト実行時間をキャプチャするため、表示遅延の問題の診断に特に役立ちます。LoAFエントリには、フレームの持続時間、ブロックの持続時間、およびフレーム中に実行された各スクリプトのソースURL、関数名、実行時間を示すスクリプトエントリの配列が含まれます。

// Long Animation Frames を監視して INP のボトルネックを見つける
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // 100ms を超えるフレームのみを調べる
    if (entry.duration > 100) {
      console.log('Long frame:', entry.duration + 'ms');

      // 貢献した各スクリプトをログに記録する
      for (const script of entry.scripts) {
        console.log(
          'Script:', script.sourceURL,
          'Function:', script.sourceFunctionName,
          'Duration:', script.duration + 'ms'
        );
      }
    }
  }
});

observer.observe({ type: 'long-animation-frame', buffered: true });

CoreDash のような RUM ツールは、LoAFデータを自動的に統合し、長いアニメーションフレームを特定のユーザーインタラクションと関連付けるため、どのページの、どの種類のインタラクションで、どのスクリプトが最悪のINPスコアを引き起こしているのかを正確に特定できます。

INP と LCP: Long Task との関連性

メインスレッドでの長いタスクは、INPと Largest Contentful Paint (LCP) の両方に影響を与えます。メインスレッドを200msブロックする JavaScript タスクは、イベント処理を遅延させ (INPを悪化させる)、またブラウザがLCP要素をレンダリングするのも遅延させます (LCPを悪化させる)。長いタスクを分割し、重要でない JavaScript を遅延させ、スクリプトの実行時間を短縮してメインスレッドを最適化すると、両方の指標を同時に改善できます。

ケーススタディ: 本番環境での INP の改善

redBus: モバイルのコンバージョンが80〜100%向上

世界最大のオンラインバスチケットプラットフォームの1つである redBus は、グローバル市場全体で Core Web Vitals の最適化に投資しました。JavaScript の実行時間の短縮とイベントハンドラの最適化に注力した結果、グローバル市場でのモバイルのコンバージョン率が80〜100%向上しました。この改善は、メインスレッドのブロック時間の短縮、サードパーティのスクリプト読み込みの最適化、コードスプリッティングの実装によるページの起動時に解析される JavaScript の量の削減を組み合わせることで実現されました。

Preply: INP が 250ms から 185ms に改善され、SEO の価値が年間推定 20万ドルに

オンライン言語学習プラットフォームである Preply は、ホームページの INP を約 250ms から 185ms に、検索ページの INP を約 250ms から 175ms に改善しました。チームは、React アプリケーションのプロファイリング、不要な再レンダリングの特定と排除、そして重要でないイベントコールバックの遅延によってこれらの成果を達成しました。改善された Core Web Vitals スコアは検索順位の上昇と相関し、オーガニック検索において年間推定20万ドルの価値に換算されました。

実際のデータが示す INP の実態

モバイルとデスクトップの INP の格差

CoreDash のデータから、モバイルの INP (p75 で 131ms) はデスクトップの INP (p75 で 48ms) の2.8倍悪いことが明らかになりました。これは、すべての Core Web Vitals 指標の中で最大のデバイス間格差です。モバイルデバイスは、プロセッサが遅く、メモリが少なく、ネットワークのレイテンシが高いため、メインスレッドのブロック時間が長くなり、イベント処理が遅くなります。デスクトップでは、インタラクションの95.6%が「良好」な INP スコアを達成していますが、モバイルではその数値は88.0%に低下します。また、モバイルユーザーはデスクトップと比べて5倍も多くの「不良」な INP イベント (9.6% 対 1.9%) を経験しています。

キーボードとポインターのインタラクションの比較

CoreDash のデータによると、キーボードのインタラクション (p75 で 75ms) は、ポインターのインタラクション (p75 で 49ms) よりも 56% 遅いことがわかります。キーボードイベントは、より多くの不良な UX をもたらす割合も大幅に高くなっています。ポインターのインタラクションでは不良な INP がわずか1.4%であるのに対し、キーボードのインタラクションでは7.4%が不良な INP となっています。この格差は、特にフォームフィールドでのキーボードイベントが、入力の検証、オートコンプリートの提案、状態の更新など、より複雑な処理をトリガーすることが多いためであると考えられます。

読み込み中のインタラクションと読み込み後のインタラクションの比較

ページ読み込み中に発生するインタラクションは、ページが完全に読み込まれた後のものよりも劇的に高い INP を示します。CoreDash のデータによると、「loading」フェーズ中のインタラクションは p75 の INP が 132ms であるのに対し、読み込み後のインタラクションはわずか 50ms です。これは 2.6 倍の違いです。「dom-content-loaded」フェーズ (75ms) の間のインタラクションでさえ、非同期スクリプトやサブリソースがまだ処理されているため、上昇した INP を示します。このデータは、ページの起動時にメインスレッドの競合を減らすために 重要でない JavaScript を遅延させる という推奨事項を強く裏付けています。

グローバルな INP 合格率

HTTP Archive の 2025 Web Almanac によると、すべてのモバイルページの77%が「良好」な INP スコアを達成しています (2022年の55%から増加)。しかし、アクセス数の多い上位1,000のウェブサイトのうち、INPに合格しているのはわずか53%です。トラフィックの多いウェブサイトは、より複雑な JavaScript、より多くのサードパーティスクリプト、より複雑な DOM 構造を持つ傾向があり、これらすべてが応答性の悪化につながっています。デスクトップでは、ページの97%が良好な INP スコアを達成しており、モバイルとデスクトップの間にあるパフォーマンスの巨大な溝が浮き彫りになっています。ラボテストにおける Total Blocking Time の中央値はデスクトップで67msですが、モバイルでは1,209msです。

よくある質問

関連ガイド

このハブページでは、Interaction to Next Paint の基礎について説明しています。INP 最適化の特定の側面に関する詳細なガイダンスについては、これらの専用記事をご覧ください。

• <strong>INP の問題の発見と修正</strong>: Search Console、RUM データ、Chrome DevTools を使用して、どのインタラクションが最悪の INP スコアを引き起こしているかを正確に特定する、段階的な診断方法です。
• <strong>INP の入力遅延</strong>: INP の最初のフェーズについて説明します。メインスレッドでの長いタスクがイベント処理をブロックする仕組みや、タスクのスケジューリング、コードスプリッティング、Web Workers を使用して入力遅延を最小限に抑える方法を学びます。
• <strong>INP の処理時間</strong>: INP の第2フェーズについて説明します。イベントハンドラのコールバックを最適化し、重要なコードを優先し、重要でない作業を遅延させ、React の並行処理機能を使用して処理時間を短縮する方法を学びます。
• <strong>INP の表示遅延</strong>: INP の第3フェーズについて説明します。DOM のサイズ、レイアウトスラッシング、クライアントサイドレンダリングが視覚的更新の遅れにどのように影響するか、また表示遅延を減らす方法について学びます。

また、これらの PageSpeed 最適化ガイドも INP の改善に役立つかもしれません。

• INP の改善: JavaScript スクロールの廃止
• async と defer: JavaScript の読み込み戦略
• JavaScript を遅延させる14の方法
• 完璧な Core Web Vitals を備えたチャットウィジェット
• 修正: 過剰な DOM サイズを避ける