Interaction to Next Paint (INP): その概要、測定方法、改善方法

Interaction to Next Paint (INP) は、クリック、タップ、キー操作などのユーザーインタラクションに対して Web ページがどれだけ素早く応答するかを測定する Core Web Vital です。INP は、ユーザー入力から JavaScript 処理を経て画面上の最終的な視覚更新までの完全なレイテンシを捕捉します。良好な INP スコアは、75 パーセンタイルで 200 ミリ秒以下です。INP は 2024 年 3 月に First Input Delay (FID) に代わって Core Web Vital となりました。

Interaction to Next Paint (INP) とは？

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

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

低い INP は、ページがユーザー入力に対してタイムリーに応答していることを意味します。高い INP は、ブラウザがインタラクションを処理して画面を十分に速く更新できないため、ページが遅く、反応がなく、または「ジャンキー（カクつく）」に感じることを意味します。

INP 対 FID: 何が変わり、なぜ変わったのか

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

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

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

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

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

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

INP にカウントされるインタラクション

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

INP にカウントされないインタラクション

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

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

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

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

1. 入力遅延 (Input Delay)

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

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

中央値では、入力遅延は最小の INP サブパートです。しかし、90 パーセンタイルでは、メインスレッド上の長いタスクがイベント処理を数百ミリ秒遅らせる可能性があるため、入力遅延が支配的な要因になります。HTTP Archive Web Almanac 2024 によると、タスクの期間を推奨される 50ms のしきい値未満に抑えている Web サイトは 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 ミリ秒未満である必要があります。

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

INP は平均ではなく 75 パーセンタイルを使用することを理解することが重要です。これは、実際のユーザーの 75% が 200ms より速いインタラクションを経験する必要があることを意味します。75 パーセンタイル方式により、ハイエンドハードウェアを使用しているユーザーだけでなく、低速なデバイスや接続を使用しているユーザーの体験も指標に反映されるようになります。

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

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

公式 INP 指標の取得

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

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

リアルユーザーモニタリング (RUM) で INP を追跡する

公式の CrUX データセットは Core Web Vitals スコアの決定的なソースですが、高度に匿名化されており、リアルタイムのモニタリングや詳細なフィルタリングはサポートされていません。そのため、Web パフォーマンスの専門家は、CoreDash のようなリアルユーザーモニタリング (RUM) ツールを利用して、実用的なリアルタイムの INP データを取得しています。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 TIP: ユーザーがページ読み込みの起動段階でページを操作すると、INP はほとんどの場合はるかに悪くなります。そのため、INP をデバッグするときは、ページ読み込み状態だけでなく、すべてのインタラクションをログに記録することは理にかなっています。

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

通常、どのページも、ほとんどのメインスレッド作業（解析、デコード、レンダリング、スクリプティング）が発生するページ起動フェーズ中は応答性が低くなります。メインスレッドをできるだけ空けておくには：

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

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

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

async function yieldToMain() {
  if ('scheduler' in window && 'yield' in window.scheduler) {
    return await window.scheduler.yield();
  }
  // Fallback for browsers without scheduler.yield()
  return new Promise((resolve) => {
    setTimeout(resolve, 0);
  });
}

// Usage: break up a long task into smaller chunks
async function processLargeDataSet(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);

    // Yield every 5 items to let the browser handle user input
    if (i % 5 === 0) {
      await yieldToMain();
    }
  }
}

requestIdleCallback で重要でない作業を延期する

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

// Instead of running analytics synchronously:
document.querySelector('.cta-button').addEventListener('click', (e) => {
  // Critical: update the UI immediately
  showConfirmation();

  // Non-critical: send analytics during idle time
  requestIdleCallback(() => {
    sendAnalyticsEvent('cta_clicked', { page: location.pathname });
  }, { timeout: 2000 });
});

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

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

// Passive listener: browser does not wait for preventDefault()
document.addEventListener('touchstart', handleTouch, { passive: true });
document.addEventListener('wheel', handleWheel, { passive: true });

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

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

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

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

formEl.addEventListener("submit", (evt) => {
  evt.preventDefault();
  formfeedbackEl.innerText = "Submitting form ... please hold on";

  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 ノード）が少ないページをレンダリングする方がはるかに簡単です。合計 1,400 未満の DOM 要素を目指し、32 レベルを超えるネストを避けてください。
2. content-visibility を使用して画面外のコンテンツを遅延レンダリングする。 content-visibility: auto CSS プロパティは、ユーザーがその近くにスクロールするまで画面外コンテンツのレンダリングを延期することで、初期レンダリングを高速化します。

/* Apply content-visibility to off-screen sections */
.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、関数名、実行時間を示すスクリプトエントリの配列が含まれます。

// Observe Long Animation Frames to find INP bottlenecks
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Only look at frames longer than 100ms
    if (entry.duration > 100) {
      console.log('Long frame:', entry.duration + 'ms');

      // Log each script that contributed
      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: 長いタスクとの関連

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

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

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

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

Preply: INP を 250ms から 185ms に改善、年間 20 万ドルの SEO 削減効果と推定

オンライン語学指導プラットフォームの 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 Vital 指標の中で最大のデバイス格差です。モバイルデバイスはプロセッサが遅く、メモリが少なく、ネットワークレイテンシが高いため、これらすべてがメインスレッドのブロック時間を長くし、イベント処理を遅くする要因となります。デスクトップでは 95.6% のインタラクションが「良い」INP スコアを達成していますが、モバイルではその数値は 88.0% に低下します。モバイルユーザーはまた、「悪い」INP イベントを 5 倍多く経験しています（9.6% 対 1.9%）。

キーボード対ポインタインタラクション

CoreDash のデータによると、キーボードインタラクション（p75 で 75ms）はポインタインタラクション（p75 で 49ms）よりも 56% 遅くなっています。キーボードイベントはまた、著しく多くの悪い体験をもたらします。キーボードインタラクションの 7.4% が悪い INP になるのに対し、ポインタインタラクションではわずか 1.4% です。このギャップは、キーボードイベント（特にフォームフィールド内）が、入力検証、オートコンプリートの提案、状態の更新などのより複雑な処理をトリガーするためと考えられます。

読み込み中対読み込み後のインタラクション

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

世界の INP 合格率

HTTP Archive Web Almanac 2024 によると、すべてのモバイルページの 74% が「良い」INP スコアを達成しています（2022 年の 55% から上昇）。しかし、最も訪問数の多い上位 1,000 の Web サイトのうち、INP に合格しているのはわずか 53% です。トラフィックの多い Web サイトは、より複雑な 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 Worker を使用して入力遅延を最小限に抑える方法について学びます。
• <strong>INP 処理時間</strong>: INP の 2 番目のフェーズの深掘り。イベントハンドラコールバックを最適化し、重要なコードを優先し、重要でない作業を延期し、React の同時実行機能を使用して処理時間を短縮する方法について学びます。
• <strong>INP プレゼンテーション遅延</strong>: INP の 3 番目のフェーズの深掘り。DOM サイズ、レイアウトスラッシング、クライアント側のレンダリングが遅い視覚的更新にどのように寄与するか、およびプレゼンテーション遅延を減らす方法について学びます。

INP を改善するために、以下の PageSpeed 最適化ガイドも役立つ場合があります。

• INP を改善する: JavaScript スクロールを捨てる
• Async 対 Defer: JavaScript 読み込み戦略
• JavaScript を延期する 14 の方法
• Core Web Vitals に最適なチャットウィジェット
• 修正: 過剰な DOM サイズを避ける