PageSpeed Insightsでサイトを測ったら、パフォーマンススコアは悪くない。それなのに「INP」の項目だけ黄色や赤になっている——そんな相談がMobilisticaにはよく届きます。INP（Interaction to Next Paint）とは、クリックやタップなどの操作から画面が反応するまでの時間を示すCore Web Vitalsの指標です。Googleの基準では200ミリ秒以下が「良好」、500ミリ秒を超えると「不良」と判定されます。
この記事でわかることは次の3点です。
- INPがPageSpeed Insightsの通常のレポートに表示されないことがある理由
- 原因を4系統に切り分けて改善する手順（一覧表つき）
- Mobilistica運営サイト4件のラボ実測データと、そこから分かること
総務省の令和6年度情報通信メディアの利用時間と情報行動に関する調査によると、インターネットの平日平均利用時間は181.8分（前年比+8.2分）です。休日も183.7分（同+4.0分）に伸びています。総務省の調査が示すこの利用時間の多くはスマートフォン経由です。タップしても画面が反応しないサイトは、この限られた時間の中で真っ先に閉じられていきます。Mobilistica編集部ではPageSpeed Insightsの計測結果とweb.devの公式解説を突き合わせながら、INPの改善手順を整理しました。
INPとは？合格ラインと「表示されないことがある」という注意点
INPは、Core Web Vitalsの3指標のうち「反応の速さ」を担当する指標です。ページ内で発生したクリック・タップ・キー入力のうち、応答に最も時間がかかった操作を基準に算出されます。web.devの公式解説では、200ミリ秒以下を「良好」、200〜500ミリ秒を「要改善」、500ミリ秒超を「不良」の3段階で定義しています。
ここでつまずきやすいのが、PageSpeed Insightsで診断しても、INPの数値が表示されないケースがあることです。理由は、INPが実際のユーザー操作をもとに算出される「フィールドデータ」専用の指標だからです。Lighthouseが行うのはページを一度読み込むだけの「ラボ」計測であり、クリックやタップのような操作を実際には発生させません。そのため、アクセス数が少ないサイトではChrome UX Report（CrUX）に十分なデータが蓄積されず、INPの欄は空欄のままになります。なぜなら、Googleが公開する基準はいずれも実ユーザーの操作を集計した値であり、シミュレーションでは代替できないからです。
INP改善の手順（4ステップ）
INPを改善する人が踏む流れは、次の4ステップに整理できます。それぞれ数分から数十分あれば着手でき、休憩の合間にも進められる作業量です。
-
ステップ1：フィールドデータの有無を確認する
PageSpeed Insightsで診断し、「Core Web Vitals（実ユーザーデータ）」の欄にINPの数値が出るかを確認します。数値が出ない場合は、次のステップで代理指標を使います。
-
ステップ2：ラボの代理指標（TBT）で暫定診断する
Lighthouseの「合計ブロック時間（TBT: Total Blocking Time）」は、メインスレッドが専有されている時間の目安です。INPそのものではありませんが、応答性のボトルネックを推測する手がかりになります。TBTが大きいページは、実際の操作でもINPが悪化しやすい傾向があります。
-
ステップ3：原因を4系統に切り分ける
「診断」タブの警告一覧を見て、サードパーティスクリプト・メインスレッドを専有するJavaScript・重い入力ハンドラ・過剰なDOM更新のどれが該当するかを絞り込みます。
-
ステップ4：対策を実施し、同条件で再計測する
次章の一覧表から対策を選び、優先度の高いものから1つずつ適用します。修正後は同じデバイス条件（モバイル/PC）で再計測し、TBTとスコアの変化を記録します。
この代理指標の実態を確かめるため、Mobilistica編集部は2026年8月時点で自社運営サイトのうち4件をPageSpeed Insights（モバイル・ラボデータ）で計測しました。結果は次の表のとおりです。
| サイト | TBT（合計ブロック時間） | LCP（参考） |
|---|---|---|
| toshidensetsu-labo.net | 0ミリ秒 | 2.3秒 |
| erii-waso.com | 30ミリ秒 | 7.1秒 |
| mobilistica.com | 40ミリ秒 | 3.2秒 |
| tabi-no-tetsuzuki.com | 50ミリ秒 | 7.0秒 |
4サイトともTBTは50ミリ秒以下で、Lighthouseのスコア上は「良好」と判定される水準です。一方でLCP改善の手順：原因の特定から実践までで扱った基準に照らすと、erii-waso.comとtabi-no-tetsuzuki.comのLCPは7秒台で「不良」の水準にあります。同じサイトでもLCPとTBT（INPの代理指標）の良し悪しは一致しない、という点は実測からも確認できました。ただし繰り返しになりますが、TBTはあくまでラボの代理指標であり、実際のINPを保証する数値ではありません。
原因別の対策一覧表
INPが遅くなる原因は、大きく5パターンに分類できます。自分のサイトの警告内容と照らし合わせながら、該当する行を探してみてください。
| 原因 | 具体的な症状 | 主な対策 | 優先度 |
|---|---|---|---|
| サードパーティスクリプトが重い | 広告タグ・解析タグの読み込みで操作への反応が遅れる | 不要なタグの削除、遅延読み込み、非同期化 | 高 |
| メインスレッドを専有するJS | 大きな処理がスレッドを塞ぎ、他の操作を受け付けない | 長いタスクの分割、必要な処理だけを実行 | 高 |
| 入力イベントハンドラが重い | クリック・タップ直後の処理に時間がかかる | 処理を必要最小限にし、重い計算は後回しにする | 中 |
| 過剰なDOM更新 | 操作のたびに大量の要素を書き換えている | 更新範囲を絞る、仮想DOMやバッチ更新を検討 | 中 |
| アイドル時間を活用していない | 優先度の低い処理がメインスレッドを圧迫している | ブラウザのアイドル時間に処理を回す | 低 |
優先度は「該当するケースの多さ」と「個々の改善幅」を基準に並べています。実装レベルの具体的な手順はweb.devのINP最適化ガイドにも載っています。
つまずきやすいポイント・注意点
INP改善で一番つまずきやすいのは、TBTを改善すればINPも自動的に改善すると思い込むことです。TBTはページ読み込み時の処理集中を測る指標であり、ユーザーが実際に操作した瞬間の応答性とは計測方法が異なります。TBTが小さくても、特定のボタンだけ重い処理が紐づいていれば、そのボタンのINPは悪化したままということがあります。
「INPは、ページのライフサイクル全体を通じて発生したすべての対象操作のうち、最も遅かった操作（または一部の外れ値を除いた場合はほぼ最も遅かった操作）にかかった時間を観察することで、ページ全体の応答性を評価する指標です」（web.dev「Interaction to Next Paint (INP)」より）
※ INPは2024年3月に、旧指標のFID（First Input Delay）に代わって正式なCore Web Vitalsに採用されました。FIDは「最初の操作」だけを見ていましたが、INPはページ滞在中のすべての操作を対象にするため、より実態に近い指標とされています。判定基準についても、Google検索セントラルのCore Web Vitalsガイドを確認すると、ランキングシグナルとして参照されるのはラボではなく実ユーザーのフィールドデータである旨が案内されています。
もう一つの注意点は、INPだけを見てLCP（表示速度）やCLS（表示の安定性）の悪化を見落とすことです。3指標は独立して評価されるため、INPを直したあとは必ず他の2指標も合わせて確認する必要があります。数値は計測のたびに数%前後変動するため、単発の計測結果だけで一喜一憂しないことも実務上は大切な心がけです。
よくある質問（INP FAQ）
INPはどれくらいの数値を目指せばいいですか？
Googleの基準では200ミリ秒以下が「良好」です。200〜500ミリ秒は「要改善」、500ミリ秒を超えると「不良」と判定されます。まずは500ミリ秒切り、次に200ミリ秒切りという2段階で目標を置くと進めやすくなります。
PageSpeed InsightsでINPが表示されないのはなぜですか？
INPは実ユーザーの操作データ（フィールドデータ）から算出される指標のため、アクセス数がChrome UX Reportの収集基準に届いていないサイトでは数値が表示されません。その場合はラボの代理指標であるTBT（合計ブロック時間）を目安に暫定診断します。
TBTを改善すればINPも改善しますか？
傾向としては近づきますが、必ず一致するとは限りません。TBTはページ読み込み時の処理集中を測るのに対し、INPは実際の操作1回ごとの応答性を測るため、計測しているタイミングが異なります。TBTの改善はINP改善の土台にはなりますが、保証するものではありません。
スマホとパソコンでINPの基準は違いますか？
基準値自体は同じ200ミリ秒ですが、スマートフォンは処理性能が低い端末が多く、同じ処理でもINPが悪化しやすい傾向があります。診断は必ずモバイルの数値を優先して確認します。
まとめ
ポイントは次の3つです。
- INPはフィールドデータ専用の指標であり、アクセス数が少ないサイトでは表示されないことがある
- ラボ環境ではTBT（合計ブロック時間）を代理指標として使い、原因をサードパーティスクリプト・JS・入力ハンドラ・DOM更新の4系統に切り分ける
- TBTの改善とINPの改善は必ずしも一致しないため、可能であれば実ユーザーのフィールドデータで最終確認する
Mobilisticaが自社運営4サイトを実測した結果では、TBTはいずれも良好な水準でしたが、同じサイトでもLCPは大きくばらついていました。応答性と表示速度は別の指標として、原因の切り分けから別々に進めるのが結局のところ近道です。施策全体の着手順を先に知りたい方は、表示速度改善の進め方：効果が大きい施策から着手する方法も参考にしてください。INPの実測記録は、今後もMobilisticaの複数サイトで継続して蓄積していく予定です。
※本記事はPageSpeed Insightsによる公開時点（2026年8月12日）の計測をもとに作成しており、測定値は測定環境やタイミングにより変動します。
※本記事は一般的な情報提供を目的としており、個人の見解を含む内容です。実際の改善効果はサイトの構成によって異なるため、ご自身のサイトでの再計測をおすすめします。
最終更新: 2026年8月12日
Mobilisticaの運営者情報はこちらをご覧ください。