INP（Interaction to Next Paint）は、2024年3月にFID（First Input Delay）と置き換わったCore Web Vitalsの応答性指標です。

導入から2年以上が経過した2026年現在も、3指標の中で最も「不合格」になりやすい指標であり、多くのサイトが改善に苦戦しています。

本記事では、INPの仕組みと判定基準、悪化する原因、2026年時点で有効な改善方法、計測ツールまでを解説します。INPを改善して、ユーザー満足度と検索パフォーマンスの両方を向上させましょう。

また、Webのご担当者であれば、ウェブサイトの表示・応答スピードがWebサイトの成果に影響を与えることはご存知だと思います。実際、あるリサーチによると、わずか0.1秒サイトスピードが向上することで購入完了率が8.4％高まるとされており、スピードとCVRには相関関係があることが示されています。

【無料ダウンロード】サイトスピード改善事例集
LCPやTTFBなどの指標の変化はもちろん、CVRやSEOがどう変化したのかまで含めた実際の改善事例を紹介しています。Webサイトの管理・改善をご担当されている方は、ぜひご活用ください。
▶ https://speedkit.gaprise.jp/case-study

INPとは？ユーザー操作への「応答性」を測る指標

INPとは、Interaction to Next Paintの略称で、ユーザーがページ内でクリック・タップ・キー入力を行ってから、画面が視覚的に反応するまでの速さを評価するCore Web Vitalsの指標です。2024年3月12日、それまで応答性指標だったFIDに代わり、正式なCore Web Vitalsとして採用されました。

たとえば、ECサイトで「カートに入れる」ボタンをタップしたのに画面が一瞬固まる、フィルタを操作しても結果がなかなか切り替わらない。こうした「操作したのに反応しない」体験を数値化したものがINPです。値が小さいほど応答性は良好で、ユーザーはストレスなく次の行動に移れます。

INPが計測する3つのフェーズ

INPは、1回のインタラクションを次の3つのフェーズに分けて計測し、その合計をレイテンシ（遅延時間）として評価します。

• • 入力遅延（Input Delay）：操作してからイベントハンドラが動き出すまでの待ち時間。メインスレッドが他のタスクで塞がっていると長くなります
  • 処理時間（Processing Time）：イベントハンドラ（JavaScript）の実行にかかる時間
  • 表示遅延（Presentation Delay）：処理が終わってから、次のフレームが画面に描画されるまでの時間

3つのうちどこがボトルネックかによって、有効な改善策が変わります。この分解が、後述する改善方法を選ぶうえでの出発点になります。

計測対象のインタラクション

INPが計測対象とするのは、次の3種類の操作です。

• • マウスのクリック
  • タッチスクリーンデバイスでのタップ
  • キーボードの押下

スクロールやマウスホバーは計測対象外です。スクロールはブラウザのコンポジタスレッドで処理されるため、メインスレッドの混雑とは切り離して扱われます。

INPとFIDとの違い

FIDは「ページ内で最初のインタラクション」の「入力遅延」だけを計測していました。そのため、JavaScriptの読み込みが終わる前の最初の1クリックさえ速ければ合格できるという構造的な弱点がありました。INPは滞在中のすべてのインタラクションを3フェーズで評価するため、実際のユーザー体験をより正確に反映します。

INPの判定基準は？200ミリ秒以下が「良好」ライン

INPの判定基準は「200ミリ秒以下：良好」「200ミリ秒超〜500ミリ秒以下：改善が必要」「500ミリ秒超：不良」です。このしきい値は2026年7月時点でも変更されておらず、LCP（2.5秒）・CLS（0.1）とあわせてCore Web Vitals 3指標の基準は据え置かれています。

ここで重要なのが、評価方法です。Googleは実ユーザーの利用データ（CrUX：Chrome User Experience Report）をもとに、モバイル・デスクトップ別に「75パーセンタイル（p75）」で評価します。つまり、実際の訪問者の75％が200ミリ秒以内の応答を体験している必要があります。平均値でも、高速な回線・高性能な端末での計測値でもありません。

また、CrUXのデータは直近28日間のローリングウィンドウで集計されます。改善を実施しても、Search Consoleなどのレポートに反映されるまでには最大で1か月程度かかる点を、社内報告やクライアント報告の際には織り込んでおきましょう。

なお、ページのINP値として報告されるのは「滞在中に観測されたインタラクションのうち、最も遅かったもの」です（操作回数が非常に多いページでは、ごく稀な外れ値が除外されます）。セッション中にたった1回でも大きく引っかかる操作があると、そのページのINPを悪化させうる。この「最悪値で評価される」性質が、INPを3指標の中で最も攻略しにくいものにしています。

なぜ2026年もINPが重要なのか？

INPは、Core Web Vitals 3指標の中で最も「不合格」になりやすい指標です。Web Almanac 2025によると、モバイルで良好なINPを達成しているページは約77％にとどまり、いまだ2割以上のサイトが200ミリ秒の基準を満たせていません。FIDからの置き換えから2年が経ち、「新指標だから様子見」というフェーズはすでに終わっています。

参照：https://almanac.httparchive.org/ja/2025/

SEO（検索ランキング）への影響

GoogleはCore Web Vitalsをランキングシステムで利用していることを公式に認めています。ただし、良好なスコアが上位表示を保証するわけではなく、コンテンツの関連性や品質が拮抗している場面で効いてくる「タイブレーカー」的な位置づけです。逆に言えば、競合とコンテンツ品質で差がつきにくい領域ほど、INPをはじめとするCore Web Vitalsの差が順位に表れやすくなります。

また、応答性の悪さはSEO以前にユーザー行動へ直接影響します。操作に反応しないページでは、ユーザーは連打（レイジクリック）や離脱に向かい、CVR低下に直結します。

AI検索時代のパフォーマンス（AIO/GEOの観点）

2026年のもうひとつの論点が、AI検索との関係です。AI OverviewsやChatGPT、Perplexityなどの生成AIがコンテンツを参照・引用する時代になり、Webパフォーマンスへの投資は「Google検索順位のためだけの施策」ではなくなりつつあります。AIのクローラー・取得システムにとっても、高速で構造が明確なページはコンテンツを取得・解釈しやすく、引用元として採用されやすい土台になるという指摘が広がっています。

「AIに引用されるコンテンツ設計（AIO/GEO）」と「引用に耐えるページ基盤（パフォーマンス）」は、2026年のWeb担当者にとって両輪と言えるでしょう。

INPが悪化する主な原因

INP悪化の最大の要因は、ブラウザのメインスレッドを長時間占有するJavaScriptです。50ミリ秒を超える「長時間タスク」が実行されている間、ユーザーの操作は処理待ちの列に並ばされ、応答が遅れます。

代表的な原因は次の4つです。

• • 長時間タスク：50ミリ秒を超える同期的なJavaScript処理。イベントハンドラ内の重い計算や、大量のDOM更新が典型です
  • サードパーティスクリプト：チャットウィジェット、ABテストツール、タグマネージャー、広告タグなどは、メインスレッド上で長時間タスクを発生させがちです
  • 巨大なDOMと強制同期レイアウト：DOM要素が多いほど再計算コストが増大します。DOMへの書き込み直後にレイアウト情報を読み取る「強制同期レイアウト（レイアウトスラッシング）」も応答を遅らせます
  • ハイドレーションの負荷：ReactなどのSPA/フレームワークでは、ページ読み込み中のハイドレーション処理がメインスレッドを圧迫し、読み込み直後の操作のINPを大きく悪化させます

なお、旧記事で紹介していた「画像ファイルの重さ」は、主にLCP（読み込み速度）の問題です。画像の最適化はページ読み込み中のメインスレッド逼迫を和らげる間接効果はあるものの、INP改善の主役はあくまでJavaScriptの制御である点を押さえておきましょう。

INPの改善方法5つ【2026年版】

INP改善の基本方針は「メインスレッドを空ける」ことです。具体的には、①長時間タスクの分割、②不要なJavaScriptの削減・遅延、③サードパーティスクリプトの監査、④CSSへの置き換え、⑤Web Workerへの処理移譲、の5つが2026年時点の定石です。

1. 長時間タスクを分割する（scheduler.yield）

50ミリ秒を超える同期処理は、小さなタスクに分割してブラウザに制御を返す（yieldする）ことで、合間にユーザー操作を処理できるようになります。従来はsetTimeoutで分割するのが定番でしたが、現在はscheduler.yield() APIを使うことで、譲歩したタスクを優先的に再開でき、よりきれいに実装できます（非対応ブラウザ向けにはsetTimeoutへのフォールバックを用意します）。

また、クリック直後にはまずローディング表示などの視覚的フィードバックだけを描画し、重い処理はその後に回す設計も有効です。「操作に反応した」とユーザーに伝わるまでの時間こそがINPだからです。

2. 不要・非クリティカルなJavaScriptを削減・遅延する

使われていないコードの削除（ツリーシェイキング）、バンドルの分割（コードスプリッティング）、初期表示に不要な機能の遅延読み込みが基本です。たとえば、ファーストビューに存在しないタブやドロップダウンのコンポーネントは、最初から全部マウントする必要はありません。Intersection Observerと動的インポートを組み合わせ、必要になったタイミングで読み込みましょう。Chrome DevToolsのカバレッジ機能を使うと、読み込まれているのに実行されていないコードを特定できます。

3. サードパーティスクリプトを監査する

チャットウィジェット、ヒートマップ、ABテストタグ、計測タグは、UIが必要としているメインスレッドを奪い合う存在です。まず「本当に全ページで必要か」を棚卸しし、必要なものも読み込みタイミングを遅らせる・軽量な代替に置き換えるなどの対処を検討します。マーケティング部門が入れたいタグとINPのトレードオフを定量的に議論できるようにしておくことが、2026年のサイト運用では重要です。

4. CSSでできることはJavaScriptでやらない

ホバーやフォーカス時のスタイル変更をJavaScriptのイベントハンドラで実装しているケースは意外と多くあります。CSSの:hoverや:focus、transitionで実現できる表現はCSSに寄せることで、メインスレッドの仕事を減らせます。アニメーションも、transformとopacityを使ったCSSアニメーションであればGPU側で処理され、INPへの影響を抑えられます。

5. 重い処理はWeb Workerへ逃がす

大量データの集計・変換、検索インデックスの構築といった計算処理は、Web Workerに移すことでメインスレッドから切り離せます。メインスレッドはUIの応答に専念させる。これがINP時代のJavaScript設計の原則です。

INPの計測方法

INPは実際のユーザー操作から算出される「フィールド指標」です。そのため計測の出発点は、実ユーザーデータ（CrUX）を確認できるGoogle Search ConsoleとPageSpeed Insightsになります。Lighthouseなどのラボツールの単発計測では、意味のあるINP値は得られません。

Google Search Console

サイト全体のINPの健康状態を把握するなら、まずSearch Consoleです。左側メニューの「ウェブに関する主な指標」レポートを開き、モバイル／PCそれぞれのタブで「不良」「改善が必要」と判定されたURLグループを確認します。なお、以前あった「ページエクスペリエンス」の単体レポートは廃止されているため、旧記事の手順とは動線が変わっています。

Search ConsoleはURLを類似グループ単位で評価するため、テンプレートによる問題（共通ヘッダーのスクリプト、全ページ共通のタグなど）があるとグループごとまとめて不合格になります。個別ページではなくテンプレート単位で原因を探すのが近道です。

PageSpeed Insights

URLを入力するだけで、そのページのCrUXフィールドデータ（直近28日間・p75）とラボ診断の両方を確認できます。見るべきは上段の「実際のユーザーの環境で評価する」に表示されるINPです。下段のLighthouseスコアはあくまで診断のヒントであり、Googleの評価対象はフィールドデータであることを混同しないようにしましょう。

Web Vitals拡張機能・web-vitalsライブラリ

Chrome拡張機能「Web Vitals」を入れると、閲覧中のページのINPをリアルタイムに確認でき、どの操作が遅かったかも把握できます。より本格的に取り組むなら、web-vitalsライブラリ（JavaScript）を自社サイトに組み込み、実ユーザーのINPと「どのインタラクションが遅いのか」を自社の分析基盤に送るRUM（リアルユーザーモニタリング）の導入を検討しましょう。CrUXは「問題があるか」は教えてくれますが、「何が原因か」までは教えてくれないためです。

LoAF APIで原因を特定する（上級者向け）

原因調査を一段深めるのが、Chrome 123から利用可能になったLong Animation Frames（LoAF）APIです。50ミリ秒を超える描画フレームについて、どのスクリプトが・どこで・何ミリ秒消費したかというスクリプト単位の内訳（attribution）を取得できます。web-vitalsライブラリのattributionビルドと組み合わせれば、「INPを悪化させている犯人スクリプト」を実データから特定できます。Chrome DevToolsのパフォーマンスパネルでも、インタラクションの3フェーズ（入力遅延・処理時間・表示遅延）を可視化できるため、ローカルでの再現・検証に活用しましょう。

まとめ：INP改善は「メインスレッドとの戦い」

ここまで、INPの仕組みと判定基準、悪化する原因、2026年時点の改善方法と計測ツールを解説してきました。ポイントを整理します。

• • INPはクリック・タップ・キー入力への応答性を測る指標で、200ミリ秒以下（p75）が「良好」。しきい値は2026年も据え置き
  • 滞在中の「最も遅い操作」で評価されるため、FID時代の「最初さえ速ければよい」対策は通用しない
  • 悪化の主因はメインスレッドを塞ぐJavaScript。改善の柱はタスク分割・JS削減・サードパーティ監査・CSS活用・Web Worker
  • 計測はSearch ConsoleとPageSpeed Insightsのフィールドデータが起点。原因特定にはRUMとLoAF APIを活用する

INPの改善はコンテンツ施策と違い、JavaScriptアーキテクチャに踏み込む技術的な取り組みです。だからこそ、一度改善すれば競合が簡単には追いつけない差別化要因にもなります。

【無料ダウンロード】サイトスピード改善事例集
LCPやTTFBなどの指標の変化はもちろん、CVRやSEOがどう変化したのかまで含めた実際の改善事例を紹介しています。Webサイトの管理・改善をご担当されている方は、ぜひご活用ください。
▶ https://speedkit.gaprise.jp/case-study