WebサイトのINPスコアを改善する方法とは？2026年SEOとユーザ体験対策ガイド

WebサイトのINPスコアをどう改善するか？ 端的な答え：ユーザーのクリック、タップ、キーボード操作などの直後、画面に次の描画が現れるまで遅延させるメインスレッドの負荷を減らす必要があります。具体的には長時間実行されるJavaScriptタスクの分割、不要なスクリプトの削除、イベントリスナーの軽量化、レンダリングを妨げるリソース最適化、外部コードの監査、実際のユーザーデータによる計測が重要です。良好なINPスコアは200ms以下、200-500msは改善領域、500ms超は「遅い」と判断されます。

INP（Interaction to Next Paint）は2026年SEOとユーザー体験の中核指標「Core Web Vitals」の一つ。Googleはページの表示速度だけでなく、表示後のユーザー操作への反応速度も重視しています。商品フィルタの開閉が遅い、カート追加ボタンが鈍い、モバイルメニューが反応しない、フォーム入力がモタつく——これらは典型的なINP問題の兆候です。

本ガイドではINPの測定方法、スコア低下の原因特定、開発者・サイト管理者・WordPress運用者が取れる最適化手順を具体的に解説します。さらに、ホスティング基盤やCDN、SSLなどインフラ面の間接的な影響も実例を交えて説明します。パフォーマンス重視の基盤選びならウェブホスティングパッケージやWordPress向けWordPressホスティングもご検討ください。

INPとは？なぜ重要なのか

INPはページ上のユーザー操作への総合応答速度を測る指標です。ユーザーがボタンをクリックしたり、タブを切り替えたり、メニューを開いたり、フォーム入力やモバイルでタップしたとき、ブラウザは処理を走らせ、JavaScriptやスタイル計算、レイアウト更新を行い、新しい画面表示を作ります。この操作から画面更新までの時間がINPとして評価されます。

以前はFID（First Input Delay）が注目されていましたが、FIDは最初の操作のみを対象とします。INPはページ滞在中の全操作を包括的に評価するため、ECサイト・ブログ・管理画面・企業サイト・会員制サイトなど幅広い用途で「本当のユーザー体験」を反映します。

Google推奨のINP基準は次の通りです：

INPはSEOだけでなく、コンバージョンにも直結します。例えばモバイルのフィルタボタンが700ms後に開くカテゴリページでは、ユーザーが「動いていない」と誤解し、再度タップしたり離脱するリスクがあります。対して150-180msで応答するUIは「速くて信頼できる」と認識されやすいです。

INPスコアの測定方法

INP最適化の前に正確な計測が不可欠です。ラボツールは推定値を示しますが、実際のユーザーデータは端末や接続、ブラウザ条件を反映します。両方のデータを併用するのが最適です。

1. PageSpeed Insightsで簡易チェック

PageSpeed InsightsはChrome User Experience Reportがあれば「実際のINP値」を提示します。モバイル・PC両方を見比べ、特にモバイルを重視しましょう。低スペック端末はメインスレッドが詰まりやすいです。INP値が200ms超なら、改善項目や診断セクションを確認してください。

2. Search ConsoleのCore Web Vitalsレポート

Google Search ConsoleのCore Web VitalsではURLグループごとに問題をリストアップします。単一ページよりも類似テンプレートの傾向が掴めます。例えば商品詳細ページ全体でINPが低いなら、テーマ・カートスクリプト・コメントプラグイン・商品バリエーションコードなどが疑われます。

3. Chrome DevTools Performanceパネル

DevToolsのPerformanceパネルでは、クリック直後にどのJavaScript関数が動いたか、どのタスクが50ms超の「長時間タスク」かを可視化できます。メニュークリックを記録し、メインスレッド上の色分けブロックをチェック。長いスクリプト、繰り返しのスタイル再計算、レイアウト処理はINPにとって危険信号です。

4. 実ユーザー監視（RUM）

大規模サイトではReal User Monitoring（RUM）が有効です。Web VitalsライブラリでINP値を収集し、URL・端末・ブラウザ・国・操作対象ごとに分析できます。例えばAndroidユーザーだけモバイルメニューのINPが620ms…と判明すれば、ピンポイントで修正可能です。

INP悪化の主な原因

INP問題はサーバー応答よりも「ユーザー操作時のブラウザ処理過多」が主因です。ただし基盤やファイル配信、キャッシュ、外部依存も間接的に負荷を増やします。

重いJavaScriptファイル

テーマ、スライダー、チャット、広告、解析、ABテスト、地図、SNSウィジェットなどで多数のJSが読み込まれる現代サイト。単にダウンロードするだけでなく、ブラウザで解析・コンパイル・実行されます。メインスレッドを占有すると操作応答が遅れます。

長時間タスク

50ms超のメインスレッド処理はlong taskと呼ばれます。300msの1タスクはクリック応答を遅延させます。例えばフィルタボタン押下時に1000商品をクライアント側で再計算するスクリプトは簡単にINPを500ms超へ悪化させます。

複雑なDOMと高コストなレイアウト

大量のHTMLノード、ネストされたコンポーネント、頻繁なスタイル変更、レイアウトスラッシング（繰り返し計測＆書き込みミス）はINPを悪化させます。特にメガメニュー、商品リスト、長大なSPAは要注意。

外部スクリプト

広告ネットワーク、トラッキングピクセル、ヒートマップ、チャットコード、SNS埋め込みなどは管理外のコード。これらが操作時にメインスレッドを使うと、独自UIも遅くなります。

WordPressプラグイン・テーマの肥大化

WordPressでは各プラグインが独自CSS/JSを追加します。例えばフォームプラグインのスクリプトが全ページで読み込まれると無駄な負荷に。画像エディタやスライダー、ポップアップもモバイルINPを損ねがちです。

INPスコア改善の実践ステップ

INP改善の核心は「測定→原因特定→負荷削減→分割→再測定」。以下は実プロジェクトでよく用いられる優先順位です。

1. 問題操作を特定

どの操作でINPが悪化しているか把握。モバイルメニュー、カート追加、フィルタパネル、検索、フォーム送信など。DevToolsで操作記録を複数回取り、Event TimingやInteractionでターゲットと時間を確認。

例：ECサイトでカテゴリフィルタボタンのINPが740ms。調査するとボタン押下時に1800DOMノード全て再描画していた。フィルタパネルを独立コンポーネント化し、リスト更新を遅延させた結果INPは190msへ改善。

2. JavaScriptパッケージサイズを減らす

未使用コードの削除が最も効果的。Bundle analyzerで肥大原因を特定。必要なモジュールだけインポート。例：大型日付ライブラリ→軽量代替やIntl APIへ。

• 不要なテーマ機能をオフ
• 不要なスライダー・ギャラリー・アニメスクリプトを非読込
• Tree shaking対応ビルドツール活用
• 管理画面コードを訪問者側へ送らない
• 古いpolyfillは対応ブラウザだけに配信

3. 長時間タスクの分割

ブラウザが操作に即応答できるよう、メインスレッドを定期的に解放。大きな計算は一度にせず分割。setTimeout, scheduler.postTask, requestIdleCallback, フレームワークのタイミング機能などを活用。目標は300msの1タスク→20-40msの小タスク群。

例：5000行テーブルのフィルタ＆再描画→まずユーザーの目に触れる50行のみ更新、残りは仮想化orバックグラウンド処理。これで操作結果が即表示され、体感が向上。

4. イベントリスナーの最適化

click, input, scroll, keydownごとに重い関数を走らせるとINPが悪化。特にinputで毎回APIリクエストや全リスト再計算はNG。DebounceやThrottleで処理頻度を調整。

• 検索欄は300ms Debounce
• スクロールはpassive listener推奨
• 多数要素に個別listener→event delegationへ
• クリック直後はまず見た目フィードバック→重い処理は後回し

5. 即時ビジュアルフィードバック

INPは「次の描画」に関連するため、操作直後に小さくても画面変化を出すのが重要。ボタンのactive状態、ローディング表示、スケルトン領域やパネルの初期表示などで「動いている」印象を与える。重いAPIレスポンス待ちでUI全体を一度に変えるのではなく、即時フィードバック＋段階的更新を設計。

6. レンダリング・レイアウトのコスト削減

JSだけでなくCSS/レイアウトもINPに影響。クリック後に多数要素のサイズ・位置・スタイルを変えるのは高コスト。CSSアニメはwidth, height, top, leftよりtransform, opacityが高速。大きなリストは仮想化を。非表示カードはDOMに保持しない。

レイアウトスラッシングに注意。ループ内で幅取得→スタイル書き→再取得…を繰り返すと遅延。読み込み・書き込み処理をグループ化するだけで大規模ページで数十ms短縮できます。

7. 外部コードの監査

各外部スクリプトについて「本当にCVに直結するか？」を問い、不要なら削除・遅延・必要なページだけ読込。チャットコードは決済ページのみならOK、全ブログ記事で即時動作は不要。広告・解析スクリプトは可能ならdefer/asyncで、重要操作の前に実行させない。

8. Web Workerで重い計算を分離

商品フィルタや大規模JSON処理、暗号化、データ変換などCPU負荷が高い場合はWeb Workerでバックグラウンド実行。メインスレッドは操作応答を維持。全てWorker化する必要はありませんが、100ms超のCPUタスクには有効です。

9. フレームワーク・ハイドレーションコストの最適化

React, Vue, Angular, Next.js, Nuxtなどでは初期ロード後のハイドレーションがINPに影響。全部をインタラクティブ化せず、アイランド構造・部分的ハイドレーション・サーバーコンポーネントなどを検討。操作不要な部分は静的に。モーダルやコメント欄、レコメンドなどは「必要時のみ読込」が理想。

10. WordPressでプラグイン負荷削減

WordPressではプラグイン一覧を整理。同機能重複プラグインは削除。フォーム・ギャラリー・スライダー・ポップアップが全ページでファイル読込していないか確認。Asset unload対応のパフォーマンス系プラグインで不要CSS/JSをページごとに無効化できます。

例：企業WordPressサイトでモバイルINPが560ms。スライダー削除＆ヒーロー領域を軽量HTML/CSS化、ポップアップスクリプトを5秒遅延、フォームJSを連絡ページ限定にした結果、INPは210ms→175msまで改善。

ホスティング・インフラがINPに与える影響

INPは主にクライアント側指標（ブラウザのメインスレッド負荷）ですが、インフラも無関係ではありません。高速なサーバー応答、適切なキャッシュ、最新PHP、HTTP/2・HTTP/3、CDN、圧縮はファイル配信を滑らかにし、初期ロード時のスレッド負荷を抑えます。

粗悪インフラではTTFB遅延、リソース遅延、キャッシュ不整合、過剰サーバー負荷などでユーザー体験が損なわれます。未キャッシュのWordPressは毎リクエストで重いPHP/DB処理を行うため、ページが操作可能になるまで遅延します。INPはLCPやTTFBと完全に分離せず、基盤最適化と併用が重要です。

• サーバー側キャッシュ導入
• PHP8.x・最新DB採用
• 静的ファイルはCDN配信
• Brotli/Gzip圧縮有効化
• SSL/TLS設定は最新に（安全な接続はSSL証明書参照）
• 新規サイトやブランド立ち上げ時は適切なドメイン選びにドメイン検索ツール活用

INP最適化の優先度一覧表

以下は一般的なサイトで、どの改善をいつ行うべきかのまとめです。効果はプロジェクトごとに異なるため、変更後はPageSpeed Insights・Search Console・実ユーザーデータで再計測を。

開発者向けINP改善チェックリスト

INP改善はチーム内で追跡可能なチェックリスト化が必須。単発の速度対策は新規プラグイン・キャンペーンコード・デザイン変更で再悪化しがちです。

• 重要テンプレートごとのモバイルINP目標は200ms以下
• Pull Request時のバンドルサイズ増加を監視
• 新しい外部スクリプト追加時はパフォーマンス評価
• DevToolsで最低限モバイルメニュー・検索・フォーム・購入操作を計測
• 長時間タスクは50ms以下へ、無理なら分割
• アニメはtransform・opacity優先
• 大規模リストはページネーション・無限スクロール・仮想化活用
• RUMデータは月次報告＆Search Console警告監視

よくあるINP最適化ミス

キャッシュプラグインだけ導入する

キャッシュは重要ですが、INPの唯一の解決策ではありません。キャッシュはページ配信を速くしますが、操作後に動く重いJSコードは自動で最適化できません。必ずコード最適化と組み合わせましょう。

ラボスコアだけ見て実ユーザーを無視する

Lighthouseテストは有用ですが十分ではありません。実ユーザーは多様な端末・通信・ブラウザでアクセス。特にローエンドAndroidはPCテストでは見えないINP問題を露呈します。

全スクリプトを無差別に遅延させる

deferやdelayは慎重に。設定ミスでメニュー・カート・フォーム・決済フローが壊れることも。重要操作用スクリプトは維持し、不要/外部コードのみコントロールして遅延させます。

画像最適化だけに注力し、操作応答を軽視

画像圧縮はLCPに有効ですが、INP問題には十分ではありません。操作後に動くコードが原因なら、画像対策だけで解決しません。Core Web Vitalsは総合的にアプローチしましょう。

2026年向けINP重視SEO戦略

2026年SEOでは技術的パフォーマンス・コンテンツ品質・信頼できるインフラを総合評価。GoogleのAI Overviewや高度な検索体験では「最速で満足度の高いページ」が優先されます。INP最適化は開発だけでなくSEO・UX・コンテンツ・インフラチームの協業が必須です。

ブログなら目次メニュー・カテゴリフィルタ・コメントフォームが即応答、ECサイトならサイズ選択・バリエーション切替・カート追加が瞬時に反応。企業サイトでは見積もりフォーム・モバイルメニュー・問い合わせボタンの遅延ゼロを目指しましょう。ユーザーが「速い」と感じれば滞在・閲覧・CVが増加します。

Hostragonsではパフォーマンス重視ホスティングや最新サーバ技術、安全なインフラを選択することでSEOの堅固な基盤を築けます。ドメイン・ホスティング・セキュリティを一元管理すれば運用負担を減らし、ユーザー体験やコンテンツ品質に集中可能です。関連ソリューションは法人ホスティング、VPSサーバー、SSL証明書ページをご覧ください。

まとめ

INP改善の本質は「ユーザー操作時にブラウザへ余計な仕事をさせない」こと。まず実データで最も遅い操作を特定し、JS負荷削減・長時間タスク分割・イベントリスナー最適化・レンダリングコスト低減・外部コード管理へ。ホスティング・キャッシュ・CDN・最新セキュリティ設定も堅実な基盤となります。

サイトをより速く、信頼でき、ユーザーに優しいものへ変えたいなら、まず主要ページのモバイルINPを計測し、本ガイドの最初の3ステップから始めましょう。インフラ面のスタートもHostragonsで比較検討し、ニーズに合ったホスティングプランをじっくり選ぶのが成功への近道です。

よくある質問（FAQ）

INPスコアはどれくらいが理想？

良好なINPは200ms以下。200-500msは改善余地あり、500ms超はユーザー体験が悪いと判断されます。特にモバイルユーザーのデータを重視しましょう。

INPとFIDの違いは？

FIDは最初の操作遅延のみ、INPはページ滞在中の全操作の応答品質を評価。INPの方が実ユーザー体験を包括的に反映します。

WordPressサイトでINPが悪化する理由は？

原因はプラグイン過多、重いテーマ、全ページ読込の無駄なCSS/JS、スライダー・ポップアップ・外部コードなど。プラグイン整理、ページごとのファイル読込制御、軽量テーマ採用で大幅改善します。

ホスティング変更だけでINPは改善する？

ホスティング単体では重いJSや長時間タスクは解決しませんが、高速サーバー・良質キャッシュ・CDN・最新PHP・安定リソース配信はINP最適化を支援します。特にWordPressでは間接的に重要です。

INP最適化の効果が出るまでどれくらい？

コードやプラグイン修正後はラボテストで即効果が出ます。Search ConsoleやChromeの実ユーザーデータでは数週間かかる場合も（十分なデータ収集が必要なため）。