INP(Interaction to Next Paint)とは、ユーザーがクリック・タップ・キーボード入力などの操作をしてから、ブラウザがその結果を次の画面描画として表示するまでの応答時間を見る指標です。
ページが早く表示されても、ボタンを押してから反応するまでに時間がかかれば「操作しにくいサイト」と感じます。 INPは、この「操作への反応の速さ」を測るCore Web Vitalsの指標です。
30秒でわかる結論
30秒でわかる結論
- INPは、ユーザー操作から次の描画までの応答時間を見る指標
- 良好の目安は200ms以下
- 200ms超〜500ms以下は改善が必要、500ms超は不良
- 主な原因は長いJavaScript処理、重いイベント処理、大量DOM更新、重いレンダリング
- INPは「入力遅延」「処理時間」「表示遅延」の3つに分けて考えると改善しやすい
- WordPressではテーマ・プラグイン・外部スクリプトが原因になることがある
- 改善は不要JS削減、長い処理の分割、イベント処理の軽量化、DOM更新の見直しから進める
INPとは?
INPは「Interaction to Next Paint」の略です。 ユーザーがページを操作してから、その操作に対する視覚的な変化が画面に描画されるまでの時間を測ります。
ユーザー操作 → イベント処理 → レイアウト・描画 → 次の画面表示
たとえば、メニューボタンをタップしたのにメニューが開くまで0.8秒かかる場合、ユーザーは「反応が遅い」と感じます。 このような操作応答性を評価するのがINPです。
INPが見るもの
- マウスクリック
- タップ
- キーボード入力
単なるマウス移動やスクロールそのものは、INPの代表的な評価対象とは異なります。
INPの基準は何ms?
| INP | 評価 |
|---|---|
| 200ms以下 | 良好 |
| 200ms超〜500ms以下 | 改善が必要 |
| 500ms超 | 不良 |
Core Web Vitalsでは、実際のユーザーデータを評価するとき、ページ訪問の75パーセンタイルを基準として見る考え方が使われます。 つまり、一部の高速な利用者だけではなく、多くのユーザーが十分速く操作できているかを見ることが重要です。
INPは何を測っている?
INPは、操作開始から次の描画までを大きく3段階に分けて考えると分かりやすくなります。
| 段階 | 意味 |
|---|---|
| 入力遅延 | 操作してからイベント処理が始まるまで |
| 処理時間 | イベントリスナーなどが実行される時間 |
| 表示遅延 | 処理後から次の描画が完了するまで |
INP ≒ 入力遅延 + 処理時間 + 表示遅延
どこに時間がかかっているかによって改善方法が変わります。
入力遅延とは?
入力遅延は、ユーザーがボタンを押してからJavaScriptのイベント処理が始まるまでの待ち時間です。
ブラウザのメインスレッドで別の長い処理が動いていると、新しいクリックやタップをすぐ処理できません。
例
ユーザーがボタンをクリック
↓
その時点で500msのJavaScript処理が実行中
↓
処理が終わるまでクリック処理を開始できない
このような状態では、イベント処理自体が短くてもINPが悪化します。
処理時間とは?
処理時間は、クリック・タップなどのイベントを受け取った後、イベントリスナーが実際に処理を行う時間です。
クリック時に大量の計算、DOM変更、外部ライブラリの処理などを一度に実行すると長くなります。
処理時間が長くなりやすい例
- クリック時に大量のJavaScriptを実行する
- 大きな配列を一括処理する
- 複雑なフォーム判定を行う
- 大量のDOM要素を書き換える
- 複数プラグインのイベント処理が重なる
表示遅延とは?
イベント処理が終わっても、ブラウザがすぐ画面を更新できるとは限りません。 スタイル計算、レイアウト、描画などが重いと、次の画面表示まで時間がかかります。
表示遅延が長くなりやすい例
- 大量のDOM要素を一度に変更する
- 複雑なCSSセレクタが多い
- 大きなレイアウト変更が発生する
- 重いアニメーション処理がある
INPはJavaScriptだけではなく、「その後に画面が描画されるまで」を含めて測る点が重要です。
INPが悪くなる主な原因
| 原因 | 影響 |
|---|---|
| 長いJavaScript処理 | 入力遅延・処理時間が増える |
| 重いイベントリスナー | 処理時間が増える |
| 大量DOM更新 | 処理・表示遅延が増える |
| 外部スクリプト | メインスレッドを占有する |
| 複雑なレンダリング | 表示遅延が増える |
| プラグイン処理 | クリック処理などへ追加負荷 |
原因1.長いJavaScriptタスク
INP悪化の代表的な原因は、メインスレッドを長時間占有するJavaScriptです。
ブラウザはJavaScript処理とユーザー操作への応答を同じメインスレッドで行う場面が多いため、長い処理が実行されている間はクリックへの反応が遅れることがあります。
改善の基本
- 不要なJavaScriptを削減する
- 長い処理を小さな処理へ分割する
- 操作直後に不要な処理を後回しにする
原因2.第三者スクリプトが多い
広告、アクセス解析、チャット、ヒートマップ、SNS埋め込みなどの第三者スクリプトもJavaScriptを実行します。
自分が書いたコードでなくても、イベント処理や長いタスクが発生すればINPへ影響します。
見直し候補
- 広告タグ
- チャットツール
- ヒートマップ
- SNSウィジェット
- ABテストツール
- 不要になった計測タグ
原因3.WordPressプラグインが多い
プラグイン数そのものだけでINPは決まりません。 ただし、フロント側へJavaScriptを大量に追加するプラグインが複数あると、操作時の処理が重くなることがあります。
影響しやすい例
- スライダー
- ポップアップ
- 高機能フォーム
- ページビルダー
- チャット
- 動的検索
初心者の判断
「プラグインを全部削除する」のではなく、フロント画面で実際にJavaScriptを追加しているものから確認します。
原因4.大量のDOM要素
DOMは、ブラウザがHTMLを画面構造として扱うための仕組みです。 ページ内の要素数が非常に多く、操作時に大量のDOMを書き換えると、スタイル計算やレイアウト処理が重くなることがあります。
特に巨大なメニュー、商品一覧、絞り込みUIなどでは注意が必要です。
INPとFIDの違い
INPは、以前Core Web Vitalsで使われていたFID(First Input Delay)に代わる応答性指標です。
| 項目 | INP | FID |
|---|---|---|
| 見る範囲 | ページ滞在中の操作全体 | 最初の操作 |
| 測る終点 | 次の描画まで | イベント処理開始まで |
| 現在のCWV | 採用 | 置き換え済み |
FIDは「最初の入力が処理開始されるまで」だけを見ていました。 INPは操作後の処理や描画まで含めるため、ユーザーが実際に感じる応答性をより広く評価できます。
INPはどこで確認する?
PageSpeed Insights
PageSpeed Insightsでは、Chrome User Experience Reportの実ユーザーデータが利用可能なページ・サイトについて、INPを確認できます。
Search Console
Search ConsoleのCore Web Vitalsレポートでは、実ユーザーデータをもとに問題のあるURL群を確認できます。
Chrome DevTools
開発者ツールのPerformanceパネルでは、実際に操作しながら遅いインタラクションを調べられます。 入力遅延、処理時間、表示遅延のどこが長いかを切り分けるのに役立ちます。
フィールドデータとラボデータを分ける
Search ConsoleやPageSpeed Insightsの実ユーザーデータは実際の利用環境を見るために使い、DevToolsは特定操作の原因調査に使う、と考えると分かりやすくなります。
INPを改善する方法
INP改善では、まず「どの操作が遅いか」を特定し、その操作の入力遅延・処理時間・表示遅延を調べます。
改善1.不要なJavaScriptを減らす
ページで使っていないJavaScriptや、すでに不要な第三者タグを削除すると、メインスレッドの空き時間を増やせる場合があります。
確認するもの
- 使っていない計測タグ
- 全ページで不要なスクリプト
- 停止済みサービスのタグ
- 重複しているライブラリ
改善2.長い処理を分割する
1つの長いJavaScript処理を複数の小さなタスクへ分けると、途中でブラウザがユーザー操作を処理しやすくなります。
1,000msの処理を一気に実行
↓
短い処理へ分割し、ブラウザへ制御を返す
ただし細かく分けすぎると全体の処理効率が落ちることもあるため、実測しながら調整します。
改善3.操作直後の不要処理を後回しにする
ユーザーがボタンを押した直後は、まず画面へ反応を返すことを優先します。
集計、ログ処理、重い計算など、次の描画前に終わらせる必要がない処理は後回しにできる場合があります。
考え方
悪い例:クリック → 重い計算 → UI更新
改善例:クリック → UI更新 → 次の描画後に重い処理
改善4.DOM更新を減らす
操作のたびに大量の要素を追加・削除・並び替えすると、JavaScript処理だけでなくレイアウトと描画も重くなります。
見直すポイント
- 一度の操作で更新する要素数
- 不要な再レンダリング
- 巨大な一覧表示
- 複雑な開閉メニュー
- 頻繁なサイズ計算
改善5.WordPressテーマ・プラグインを切り分ける
WordPressでは、INP悪化の原因がテーマやプラグインのJavaScriptにあることがあります。
メニュー・フォーム・検索など
本番で一括停止しない
フォーム、EC、セキュリティなど重要機能が止まる可能性があります。可能ならステージング環境で1つずつ切り分けます。
サーバーを速くすればINPは改善する?
改善する場合はありますが、INPの中心はブラウザ上の操作応答性です。
サーバー応答が遅く、操作時にAPI通信を待ってからUIを更新する設計なら影響します。 一方、重いJavaScriptやDOM処理が原因なら、高性能サーバーへ変更しても直接は解決しません。
原因で判断する
サーバー待ちが原因ならサーバー・APIを改善。
JavaScript処理が原因ならフロントエンドを改善。
同じ「遅い」でも対策は違います。
キャッシュでINPは改善する?
ページキャッシュは初期表示を速くするのに有効ですが、クリック後の重いJavaScript処理を直接軽くするものではありません。
そのため「キャッシュを入れればINPも必ず改善する」とは考えないでください。
LCPなど読み込み性能と、INPなど操作応答性は原因が異なる場合があります。
INPとLCP・CLSの違い
| 指標 | 見るもの |
|---|---|
| LCP | 主要コンテンツの表示速度 |
| INP | ユーザー操作への応答速度 |
| CLS | レイアウトの安定性 |
LCP=表示
INP=操作
CLS=ズレ
3つともCore Web Vitalsですが、改善ポイントは異なります。
INPとSEOの関係
INPはCore Web Vitalsの1つで、Googleがページエクスペリエンスを理解するための指標群に含まれます。
ただし、INPを200ms以下にしただけで検索順位が大きく上がると断定することはできません。 Google検索ではコンテンツの関連性や品質など、多くのシグナルが使われます。
SEOだけを目的に改善しない
INP改善の本来の目的は、ボタンやメニュー、フォームがすぐ反応する使いやすいページにすることです。
どんなサイトでINPを重視する?
シンプルなブログ
重要度:中
操作が少なければ問題が出にくいですが、メニュー・検索・広告スクリプトは確認します。
会社サイト
重要度:中
ナビゲーション、フォーム、アコーディオンなどの操作が遅くないか確認します。
ECサイト
重要度:高
検索、絞り込み、カート、数量変更など操作が多いためINPの影響を受けやすくなります。
Webアプリ
重要度:非常に高
ユーザー操作が中心なので、応答の遅さが直接使い勝手に影響します。
教科書判定
INPが悪いときは、まず「どの操作が遅いか」を特定する
初心者が最初にやるべきことは、サーバー変更やプラグイン全削除ではありません。
PageSpeed Insights・Search Consoleで問題を把握 → DevToolsで遅い操作を再現 → 入力遅延・処理時間・表示遅延のどこが長いか確認という順番で進めます。
WordPressでは、フロント側へJavaScriptを追加するテーマ・プラグイン・第三者タグを優先して確認してください。 目標は200ms以下ですが、数値だけでなく「押したらすぐ反応する」サイトを作ることが本質です。
FAQ
Q.INPは何msなら良好ですか?
200ms以下が良好の目安です。200ms超〜500ms以下は改善が必要、500ms超は不良と評価されます。
Q.INPが悪いのはサーバーが遅いからですか?
必ずしもそうではありません。重いJavaScript、イベント処理、DOM更新などブラウザ側の処理が原因になることが多くあります。API応答待ちなどサーバーが関係するケースもあるため切り分けが必要です。
Q.キャッシュプラグインでINPは改善しますか?
初期表示には有効でも、操作後のJavaScriptが重い場合は直接改善しないことがあります。INPでは操作時のメインスレッド処理を確認してください。
Q.INPとFIDは同じですか?
違います。FIDは最初の操作からイベント処理開始までを見ていました。INPはページ滞在中の操作を幅広く見て、次の描画まで測定します。
Q.INPを改善すれば検索順位は必ず上がりますか?
必ずではありません。INPはCore Web Vitalsの1つですが、検索順位はコンテンツの関連性や品質など多数の要因で決まります。ユーザー体験改善を第一目的にしてください。
まとめ
この記事の結論
- INPはユーザー操作から次の描画までの応答時間を測る
- 200ms以下が良好、500ms超は不良
- 入力遅延・処理時間・表示遅延の3段階で原因を切り分ける
- 長いJavaScriptやイベント処理が代表的な原因
- 第三者スクリプトやWordPressプラグインも影響する
- 不要JS削減、長い処理の分割、DOM更新削減で改善する
- サーバー高速化だけでは直らない場合が多い
- PageSpeed Insights・Search Console・DevToolsを使い分ける
INP改善では、数値だけを見るのではなく「どの操作をしたときにユーザーが待たされるのか」を探すことが重要です。 原因となる操作を特定し、その処理を軽くするところから始めてください。
「Core Web Vitalsとは?SEOとの関係を初心者向けに解説」「LCPとは?原因と改善方法を解説」「CLSとは?原因と改善方法を解説」もあわせて確認してください。