Interaction to Next Paint (INP) とは：計測方法と改善方法

Interaction to Next Paint (INP) は、クリック、タップ、キー押下などのユーザー操作に対するWebページの応答性を計測するCore Web Vitalsの指標です。ユーザーの入力からJavaScriptの処理を経て、画面が視覚的に更新されるまでの全体の遅延を計測します。75パーセンタイルで200ミリ秒以下であれば良好なスコアです。2024年3月にFirst Input Delay (FID) に代わり、Core Web Vitalsに採用されました。

Interaction to Next Paint (INP) とは

INPは、ページの応答性を評価するCore Web Vitalsの指標です。訪問中のすべての操作を対象とし、ページごとに1つの数値を報告します。

クリック、タップ、キー押下が発生するたびに、ブラウザは入力から画面の次のフレームが描画されるまでの時間を計測します。その訪問の中で最も遅かった操作が、その訪問のINPになります。クリックが多いページでは、Chromeは50回の操作ごとに1つの外れ値を除外します。これは実質的におよそ98パーセンタイルに相当します。

INP vs FID：変更点とその理由

2024年3月、INPはFirst Input Delay (FID) に代わり、Core Web Vitalsの正式な指標となりました。GoogleがFIDを廃止したのは、2つの重要な点を見落としていたからです。

1つ目は、FIDがページ内の最初の操作しか計測していなかった点です。最初のクリックが速くても、その後の操作が遅ければ、ユーザー体験が悪くてもFIDは合格と判定してしまいます。対照的にINPは、訪問中のすべての操作を計測します。

2つ目は、FIDが入力遅延フェーズしか計測していなかった点です。つまり、ブラウザがイベントの処理を開始するまでの待機時間しか捉えていませんでした。イベントハンドラーの実行時間（処理時間）や、結果を画面に描画するまでの時間（表示遅延）は無視されていました。INPはこの3つすべてを計測します。

ほぼすべてのサイトがFIDに合格していました。しかし、その多くがINPでは不合格になっています。初回以降の操作や、最初のクリック後の処理が遅いためです。

INPが計測する操作とは

INPが計測するのは、個別の操作のみです。クリック、タップ、キー押下がこれに該当します。

INPの計測対象となる操作

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

INPの計測対象外となる操作

• スクロール（詳細は後述）
• ホバー（マウスオーバー）
• ドラッグ（ただし、ドラッグを開始するpointerdownは計測対象になり得ます）
• ユーザー入力を伴わずに実行されるCSSトランジションやアニメーション

スクロール操作そのものは計測対象外です。しかし、スクロールに関するコードは2つの形でINPを悪化させる要因になります。1つ目は、アンカーリンクのクリックを起点にJavaScriptによるスクロールアニメーションを開始する場合です。クリック自体が操作であり、その中でスクロール処理が実行されます。2つ目は、scrollイベントごとに実行されるスクロールハンドラーがmain threadを占有し、次のクリックが待たされる場合です。CSSの scroll-behavior: smooth を使えば、この両方を回避できます。

INP操作を構成する3つのフェーズ

INPが計測するすべての操作は、連続する3つのフェーズで構成されています（Googleはこれらを「サブパート」と呼んでいます）。INPの値はこの3つの合計であり、フェーズごとに対策が異なります。

1. 入力遅延（Input Delay）

**入力遅延**は、クリックが発生してからイベントハンドラーが実行を開始するまでの時間です。クリック処理は、その時点でmain threadで実行されているタスク（タグマネージャー、同意バナーのスクリプト、ハイドレーション中のフレームワークなど）の完了を待たなければなりません。

入力遅延が最も悪化するのはページの読み込み中です。CoreDashのデータによると、読み込み中のクリックは読み込み完了後のクリックに比べて2倍以上遅くなっています（具体的な数値は後述）。

2. 処理時間（Processing Time）

**処理時間**は、その操作に対するイベントハンドラーの実行にかかる時間です。フォームのバリデーション、ステートの更新、アナリティクスの呼び出しなどが該当します。

イベントハンドラーが高負荷なDOM操作、同期APIの呼び出し、重いループ処理などを実行すると、処理時間が増加します。典型的な例が、クリックハンドラー内での dataLayer.push() です。画面が更新される前にタグマネージャー内の全タグが実行されてしまいます。対策は、pushの前にyieldすることです。

3. 表示遅延（Presentation Delay）

**表示遅延**は、イベントハンドラーの終了から画面上の次のフレームが描画されるまでの時間です。スタイルの再計算、レイアウト、ペイントの処理が含まれます。

DOMのサイズが大きかったり深くネストされていたりするページは、スタイルの再計算やレイアウトに時間がかかります。また、ステート変更後に大規模なコンポーネントツリーを再レンダリングするシングルページアプリケーション（SPA）でも、表示遅延が高くなりがちです。

INPスコアの評価基準

合格基準を満たすには、ページ訪問のp75（75パーセンタイル）におけるINPが200ミリ秒以下である必要があります。

• INPが200ミリ秒以下：ページの応答性は「良好（Good）」です。
• INPが200ミリ秒〜500ミリ秒：ページの応答性に「改善が必要（Needs Improvement）」です。
• INPが500ミリ秒超：ページの応答性は「不良（Poor）」です。

INPは75パーセンタイルを使用するため、全訪問の75%でINPを200ミリ秒以下に抑える必要があります。これには低スペックなスマートフォンを利用する訪問者も含まれます。

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

INPの計測にはクリック、タップ、入力を行う実際の訪問者が必要なため、評価の基準となるのはfield dataです。ページを読み込むだけのlab testにはINPが存在しません。Lighthouseは代わりにTotal Blocking Timeを表示しますが、これは読み込み中にmain threadがどれだけビジーかを示すだけであり、フィルターメニューのクリックについては何も分かりません。

公式のINP指標を確認する

公式なINPデータはCrUX（Chrome User Experience Report）から提供されます。PageSpeed Insightsでは、指定したURLまたはオリジンについて、過去28日間のChromeデータにおける75パーセンタイルを確認できます。CrUX Visはここ数か月の推移を可視化し、BigQueryのCrUXデータセットには全オリジンの月次データが蓄積されています。

Google Search Consoleは、Core Web VitalsレポートでURLをグループ化します。不合格のグループは、「INP issue: longer than 200ms (mobile)」や「INP issue: longer than 500ms (mobile)」として代表的なURLとともに表示されます。過去28日間のデータが集計されるため、修正を本番公開してから2週間経っても、表示内容の半分は修正前のサイトのデータです。

RUMでINPを追跡する

CrUXが教えてくれるのはページグループが不合格であるという事実だけで、どのボタンが原因かまでは分かりません。それを突き止めるにはRUMが必要です。CoreDashでは、まずモバイルのINP p75を確認し、クリックされた要素や読み込み状態ごとに内訳を分析します。

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

Chrome DevToolsのPerformanceパネルを開きます。ページ内をクリックして操作すると、現在のセッションのINPが表示され、各操作とその3つのフェーズが記録されます。クリックしながらトレースを記録すれば、main threadで何が実行されたかを確認できます。Core Web Vitals Visualizer拡張機能を使えば、ページ上で直接INPを確認することも可能です。

実機でデバッグを行うには、Googleの Web Vitals JavaScriptライブラリ を使って個々の操作をコンソールに出力します。

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

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

Interaction to Next Paintの改善方法

他のクリックがすべて速くても、たった1回操作が遅いだけで訪問全体のINPが悪化します。3つのフェーズごとに対策を進めてください。

PageSpeed TIP: 操作ごとにページの読み込み状態を記録してください。読み込み中の遅いクリックと、読み込み完了後の遅いクリックでは、必要な修正が異なります。

1. 入力遅延の最小化：main threadのlong taskを防ぐ

main threadの処理の大部分はページの起動（読み込み）時に発生します。main threadをビジーにさせないためのポイントは以下の通りです。

• 未使用のコードを削除する。DevToolsのCoverageパネルを確認すれば、各スクリプトで実行されていないコードの割合が分かります。残りの部分はtree shakingやcode splittingで対処します。
• 重要でないコードはブラウザのアイドル時に読み込む。ページの読み込み開始から500ミリ秒の間に、チャットウィジェットが本当に必要でしょうか。急を要さないスクリプトは、requestIdleCallback() を使ってブラウザがアイドル状態のときにのみ実行されるようスケジュールします。
• クリックの背後にあるlong taskを特定する。読み込み中にクリックしながらPerformanceパネルでトレースを記録します。クリックが届いた瞬間に実行されていたタスクこそ、最優先で修正すべき処理です。
• scriptタグに async や defer を適用して、JavaScriptがHTMLパーサーをブロックしないようにします。最初の数秒間に誰も必要としないスクリプトは、後回しにできます：JavaScriptを遅延させる14の方法。
• パッシブリスナーに関する助言は無視する。INP対策として { passive: true } が推奨されることがよくあります。これはスクロールを滑らかにするだけで、INPには何の影響もありません。

scheduler.yield() でlong taskを分割する

ブラウザのmain threadで動作するJavaScriptは、「run to completion（完了するまで実行）」モデルに従います。タスクが一旦開始されると、終了するまでmain threadをブロックし続けます。50ミリ秒を超えるlong taskは、ブラウザがユーザー入力に応答するのを妨げます。scheduler.yield() を使えば、コードの実行を継続する前に、ブラウザが待機中のクリックを処理する隙間を作ることができます。詳細は main threadへの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);
  });
}

// 使い方: long taskを小さなチャンクに分割する
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 });
});

2. 処理時間の最小化：即座にフィードバックを返す

訪問者がフォームの送信やカートへの商品追加といった操作を行った際、UIの更新をサーバーからの応答待機にしてはいけません。「送信中…」「カートに追加中…」といった視覚的フィードバックを即座に返し、実際の処理はバックグラウンドで完了させてください。

また、重要な視覚的更新を行った後は、速やかにmain threadへyieldしてください。JavaScriptは「run to completion」モデルに従うため、コールバック内のすべてのコードが実行完了するまでmain threadをブロックします。意図的にyieldのポイントを作れば、ブラウザにレイアウトの更新を許可した上で、残りの緊急でないコードを実行できます。

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）では、カウンターが1つ変わっただけなのに、操作のたびにページの半分を再レンダリングしてしまいます。React DevToolsやReact Scanを使えばその様子が確認できます。大半の場合、ツリー上層にある1つのContext Providerが配下の全要素を再レンダリングしているのが原因です。

レンダリングを高速化するための2つの原則：

1. DOMを小さくシンプルに保つ。浅くフラットで小さなDOMは、深くネストされた大規模なDOMよりも高速にレンダリングされます。Lighthouseは、DOM要素が1,400個を超えるページや、ネストが32階層を超えるページに警告を出します。
2. content-visibility を使って画面外のコンテンツを遅延レンダリングする。CSSプロパティの content-visibility: auto は、ユーザーが近くまでスクロールするまで画面外コンテンツのレンダリングを遅延させることで、初期レンダリングを高速化します。

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

Long Animation Frames (LoAF) API によるINPのデバッグ

Long Animation Frames (LoAF) APIは、レンダリングに50ミリ秒以上かかったフレームの詳細情報（その最中に実行されたスクリプトを含む）を提供します。

従来のLong Tasks APIとは異なり、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とLCP：long taskによる相互影響

main thread上のlong taskは、INPと Largest Contentful Paint (LCP) の両方に悪影響を及ぼします。JavaScriptタスクがmain threadを200ミリ秒ブロックすると、イベント処理が遅れるだけでなく（INPの悪化）、ブラウザによるLCP要素のレンダリングも遅れます（LCPの悪化）。long taskの分割、緊急性の低いJavaScriptの遅延、スクリプト実行時間の削減によってmain threadを最適化すれば、両方の指標を同時に改善できます。

本番環境におけるINP改善事例

redBus：INPを72%改善し、売上が約7%増加

オンラインバス予約プラットフォームのredBusは、自社のRUMデータから予期せぬ低速な操作を発見しました。検索ページではスクロールイベントのたびにスクロールハンドラーが発火してmain threadを占有していたため、debounce処理を導入しました。別のページでは入力欄が変更されるたびにstate reducerが実行されていたため、呼び出し頻度を抑えました。結果として該当ページのINPは72%改善し、redBusの売上は約7%増加しました。（web.devのredBus事例紹介）

Preply：Next.jsサイトでINPを250msから185msに短縮

Next.jsを採用しているオンライン語学学習プラットフォームのPreplyは、ホームページのINPを約250ミリ秒から185ミリ秒へ、検索ページを175ミリ秒へと改善しました。React Server Componentsは使用していません。長いリストの仮想化、キーボードイベントのdebounce、負荷の高いコンポーネントのメモ化、ツールチップによるページ全体の再レンダリング防止、プライバシーバナーのステート管理修正などを実施しました。着手前の試算では、両ページを200ミリ秒未満に改善することで、検索トラフィックから年間約20万ドルの価値がもたらされると見積もられていました。（Preplyエンジニアリングブログ）

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

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

CoreDashのデータでは、モバイルのINP（p75で131ミリ秒）はデスクトップ（48ミリ秒）の2.8倍に達します。スマートフォンはCPU性能が低いため、同じJavaScriptであってもmain threadを長時間ブロックしてしまいます。デスクトップでは操作の95.6%が「良好」であるのに対し、モバイルでは88.0%にとどまり、「不良」の割合はモバイルの方が5倍も高くなっています（9.6% 対 1.9%）。

キーボード操作とポインター操作の比較

CoreDashのデータによると、キーボード操作（p75で75ミリ秒）はポインター操作（p75で49ミリ秒）よりも56%遅いことが分かっています。また、キーボード操作では「不良」な体験となる割合も約5倍に上ります（ポインター操作のわずか1.4%に対し、キーボード操作は7.4%）。特にフォームフィールドにおけるキーボードイベントでは、バリデーション、オートコンプリート、ステート更新が頻繁にトリガーされるためです。

読み込み中と読み込み完了後の操作比較

ページの読み込み中に行われた操作は、読み込み完了後の操作に比べてINPが大幅に高くなります。CoreDashのデータによると、「loading」フェーズ中の操作のp75 INPは132ミリ秒で、読み込み完了後の50ミリ秒と比べて2.6倍の差があります。「dom-content-loaded」フェーズ中の操作（75ミリ秒）でも、非同期スクリプトやサブリソースの処理が続いているためINPの上昇が見られます。対策は、起動時に実行するJavaScriptを減らすことです：後回しにできるものは遅延させてください。

Web全体におけるINPの状況

2026年8月のCrUXリリースでは、INPが「良好」なオリジンの割合は85.3%となり、3月の87.2%から低下しました。その間INPは毎月悪化しており、2025年8月（85.7%）と比較して悪化した唯一のCore Web Vitals指標となっています。Chromeチームはこれを懸念事項としていますが、明確な理由はまだ特定されていません。

2025 Web Almanac でも端末間の顕著な格差が示されています。デスクトップページの97%が「良好」なINPを達成しているのに対し、モバイルでは77%にとどまります。最も改善が見られた上位1,000サイトでも、モバイルで「良好」な割合は53%から63%への向上でした。一方で、モバイルにおけるTotal Blocking Timeの中央値は1,209ミリ秒から1,916ミリ秒へと58%増加しています。

よくある質問（FAQ）

関連ガイド

INPの各パートには個別の詳細ガイドがあります：

• <strong>INP問題の特定と修正</strong>：Search Consoleのレポートから低速な操作の特定まで、RUMデータとDevToolsを活用した調査方法。
• <strong>INPの入力遅延（Input Delay）</strong>：クリックを待たせるlong taskへの対処法。
• <strong>INPの処理時間（Processing Time）</strong>：イベントハンドラーの最適化と、画面更新後に実行できる処理。
• <strong>INPの表示遅延（Presentation Delay）</strong>：DOMサイズ、レイアウトスラッシング、再レンダリングの抑制。

PageSpeed関連ガイド：

• INP改善：JavaScriptスクロールをやめる
• async vs defer：JavaScript読み込み戦略
• JavaScriptを遅延させる14の方法
• Core Web Vitalsに影響を与えないチャットウィジェット
• 修正方法：過度なDOMサイズの回避