INPが悪化する意外な要因｜速いはずのサイトが遅いと感じる原因・理由
SEO「PageSpeed Insightsで点数も高いのに、なぜかINPが悪い」
「操作しても反応が遅いと言われるが、読み込みは速いはず」
こうした違和感を感じたことはないでしょうか？今回は、“一見速そうなサイト”でもINP（Interaction to Next Paint）が悪化してしまう、意外な要因について解説します。
表示が速くても、操作の応答が遅ければNG
INPはユーザーの操作（クリックやタップ、キーボード操作など）に対して、視覚的な反応が表示されるまでの「最大の遅延」を測定する指標です。
たとえLCPやFCPで高速表示されていても、ボタンを押しても何も起きなかったり、反応までワンテンポ遅れたりする場合、ユーザーは「遅い」と感じます。これが、INPの悪化につながるのです。
- 意外な盲点1：JavaScriptの後処理（イベント処理）が重い
- ページの初期表示は速いけれど、ユーザー操作後に発火するJavaScript（例：モーダルの表示、入力フォームの検証、カート処理など）が重たいケースがあります。
特に、下記のようなパターンは注意が必要です。- 無駄に大きなライブラリ（jQuery UIなど）をすべて読み込んでいる
- クリックイベントに重い処理（API通信や画像の描画）をそのまま書いている
- DOMの大量書き換えやレイアウトの再計算を伴う処理が入っている
- 意外な盲点2：外部コードの“操作応答ブロック”
- 例えば以下のようなコードが操作の妨げになることがあります：
- 広告のクリックトラッキングコード（clickイベントを遅らせる）
- アナリティクス計測（イベント処理に割り込み）
- SNSシェアボタンの描画（DOMの再構成）
- チャットウィジェットの読み込み（CPU使用率増）
- 意外な盲点3：視覚的な変化が遅れて起きるUI設計
- INPは「ユーザーが操作したあと、画面がどう変化したか」を評価するため、視覚的なフィードバックが遅れるUIは不利になります。
- ボタンを押しても「押した感触（影・アニメーション）」がすぐ出ない
- 送信後にローディングアイコンが遅れて表示される
- タブの切り替えなどがふわっと遅れて始まる
INP改善は“操作の瞬間”にこだわるべき
INP対策というとJavaScriptの削減やコードの遅延読み込みが思い浮かびがちですが、最も重要なのは「操作直後の処理をいかに軽く、早く返すか」です。
- 操作後の処理を最小限にする
- 遅延処理は非同期に逃がす（setTimeoutやWeb Workerなど）
- まずは視覚的なフィードバックを即返す（押した感、ロード中アイコンなど）
特にINPは「最大の遅延時間」なので、1つでも非常に重い処理があれば、それが指標全体を引き下げてしまいます。
速そうなUIが“遅く見える”理由を正しく知ろう
INPが悪化する要因は、ページ表示の速さとは別軸にある「操作後の体験」に集中しています。
「表示は速いのに、なぜか遅く感じられる」――その原因の多くはJavaScriptとUI設計の中に潜んでいます。
次回は、こうした“INP対策に傾倒しすぎるリスク”や“他指標とのバランス”について掘り下げます。
- 執筆者：西部俊宏
- 株式会社Webの間代表取締役。上場企業でのSEOやWebサイト構築実績多数。ECサイトのカスタマイズ経験も多数あり。
- 会社概要はこちら
「ECサイトをより便利にしたい」「もっと集客したい」ECカスタマイズはお任せください
