「PageSpeed Insights では悪くないのに、Search Console の Core Web Vitals では不良 URL が増える」「開発側の高性能な検証端末では問題が見えないのに、営業や編集の端末では押した直後にもたつく」。INP 改善の相談は、この食い違いから始まることが少なくありません。ここで感覚に寄せると、修正はほぼ外れます。INP は見た目の速さではなく、クリック、タップ、キーボード入力に対して次の描画が返るまでの遅れを見る指標だからです。Interaction to Next Paint (INP) でも、ページ滞在中の操作全体を見て、最も遅い反応を代表値として扱う考え方が示されています。
まず結論を先に示します。INP 改善で最初に決めるべきなのは、施策ではなく計測の順番です。 多くの事業サイトでは、`Search Console → PageSpeed Insights → Chrome DevTools → 実機確認` の順で固定して進めるのが基本になります。この順番を崩して先にコードを眺めても、重い処理を特定する前に論点が広がりがちです。INP は web.dev: Web Vitals で示されている通り、75 パーセンタイルで 200ms 以下が良好、200ms 超 500ms 以下が改善余地あり、500ms 超が不良です。ローカル PC で一度触って「問題なさそう」と言い切る進め方は、最初から見誤る可能性が高い。
加えて、Google の ページ エクスペリエンス では、Core Web Vitals は検索上の評価材料の一つですが、それだけで順位が決まるわけではないと明示されています。だからこそ、INP 改善は「満点を取りにいく作業」ではなく、事業に効く操作遅延を先に減らす作業として進める必要があります。JPSM SEO 編集事業部でも、INP を見るときは全ページを広く触りません。最初の二週間で、重要ページ群を三つまで、代表 URL を五本まで、遅い操作を二つまでに絞ります。ここを広げすぎると、改善の筋より会議の回数が増えます。
INP改善は最初に計測の順番を固定して始める
INP 対策で最も多い失敗は、初手で実装案を並べることです。やるべき順番は逆です。先に「どこが悪いか」を広くつかみ、その後に「なぜ遅いか」を狭く確定する。これを守ってください。 具体的には、Search Console で悪化したページ群をつかみ、PageSpeed Insights で仮説を立て、Chrome DevTools: Performance 機能 で再現し、最後に実機で違和感が消えたかを確かめます。この順番なら、改善前後の説明が通ります。
例外もあります。新規公開直後で Search Console に十分なデータがないページ、流入が少なく CrUX が付かないページ、会員向け画面のように外部から代表 URL を取りにくい画面では、Search Console 起点が成り立ちません。その場合だけ、PageSpeed Insights と実機での再現から入り、後で Search Console の回復確認に戻る進め方が妥当です。ただし、例外だからといって DevTools を先に開いてよいわけではありません。仮説なしにトレースを見ても、長いタイムラインのどこを根拠に重いと判断するかがぶれます。
四つのツールを同時に回してはいけない理由
INP 改善では、四つのツールを並行して触るより、役割を分けて使ったほうが早く進みます。次の表のように、各ツールには「何を決めるために使うか」の違いがあります。
ツール | 決めること | 強い場面 | 弱い場面 | 先に使うべきか |
|---|---|---|---|---|
Search Console | どのページ群から着手するか | サイト全体の不良群を絞るとき | 原因の断定 | はい |
PageSpeed Insights | 何が主因かの仮説を置く | 実利用データと検証データを並べるとき | 実装判断を確定するとき | はい |
Chrome DevTools | どの処理が次の描画を止めているか | 重い操作を再現できるとき | 対象ページが定まっていないとき | はい |
実機確認 | 利用者の体感が改善したか | 中価格帯端末や回線差が大きいとき | 原因分析そのもの | 最後 |
この表で外してはいけない点は一つです。Search Console と PageSpeed Insights は「どこを見るか」を決める道具、DevTools は「何を直すか」を決める道具、実機は「直っているか」を確かめる道具です。 ここが混ざると、PageSpeed Insights の提案一覧がそのまま開発タスクになり、INP の主因ではない画像圧縮や CSS 調整が先に走ります。LCP や CLS も同時に悪いなら、Core Web Vitals改善の進め方 最新評価軸に合わせて表示速度と操作体験を立て直す を並行して確認し、指標ごとの優先順位を切り分けてください。
Search Consoleで直すページ群を先に決める
Search Console の Core Web Vitals で最初に見るべきなのは、不良 URL の総数ではありません。見るべきなのは、どのページ群が同じ原因でまとめて落ちているかです。 ここを外すと、記事詳細 300 本、カテゴリ 80 本、フォーム 20 本を同じ重みで扱うことになり、施策の焦点がぼやけます。INP 改善は URL 単位よりテンプレート単位で考える場面が多く、特に一覧、検索、絞り込み、フォーム、ログイン導線は共通部品の影響を受けやすい。
実務では、次の三条件を満たすページ群から着手すると判断しやすくなります。月間流入の 20% 以上を占める、コンバージョン導線まで二クリック以内、同じ UI 部品を複数ページで共有している。 この三つが重なるなら最優先です。反対に、不良判定でも流入が極端に少なく、共有部品もなく、事業指標にも近くないページ群は後回しで構いません。INP は全ページを一斉に直すより、成果に近い導線を確実に軽くしたほうが価値が出ます。
ここでの推奨は明確です。最初に追うページ群は三つまで、代表 URL は一群につき一〜二本までに絞るべきです。 月間 PV 10 万未満のサイトなら、まず一群で十分です。10 万〜100 万なら二群、100 万超でテンプレートが多い場合のみ三群まで広げてください。これ以上広げると、改善ではなく調査のための調査になりやすい。例外は、問い合わせフォームや資料請求のように流入は少なくても事業への影響が大きいページです。この場合は流入規模より CV への距離を優先してください。
まず不良群より事業影響の大きい群を見る
Search Console を見ていると、不良 URL の件数が多い群に目が向きがちです。しかし、件数の多さと直す価値は一致しません。 たとえば、記事詳細 500 本が 520ms 前後で不良、問い合わせフォーム 8 本が 430ms で改善余地あり、という状態なら、先に見るべきは後者です。フォームの 430ms は基準上は不良ではなくても、送信直前の遅れは完了率に直結しやすいからです。Google が ページ エクスペリエンス で強調しているのも、点数を飾ることではなく、使いやすさを高めることです。
事業影響の判断が曖昧なら、計測設計を先に整えてください。Search Console だけでは「どのページ群が CV に近いか」を読み切れないため、GA4 のイベント設計が粗いサイトでは優先順位が必ずぶれます。流入経路、問い合わせ到達、送信完了のつながりが見えていないなら、先に GA4の使い方を初心者向けに整理 SEO実装で迷わない計測設計と活用の基本 を見直すほうが早い。INP の改善は、数値の赤を黄色に変える仕事ではなく、重要導線の離脱を減らす仕事だからです。
Search Console で残すべきメモも決めておきます。ページ群ごとに、`共通ヘッダーの有無`、`絞り込み UI の有無`、`フォーム入力の有無`、`同意バナーの表示条件`、`外部タグの本数`、`モバイル流入比率` を一行でまとめてください。このメモがあると、後の DevTools で見るべき観点が一気に絞れます。反対に、この整理なしに PageSpeed Insights を十本分回すのは非効率です。検索結果ページ、記事ページ、フォームページを同じ土俵で比べても、打ち手はそろいません。
PageSpeed Insightsは仮説を二つまで絞る
PageSpeed Insights の使い方で差が出ます。ここを「改善提案を読む画面」として使うと、修正項目ばかり増えて成果が出ません。PageSpeed Insights は、INP が悪い理由の仮説を二つまでに絞るために使うべきです。 三つを超えたら、優先順位付けに失敗しています。INP 改善で重要なのは、提案を網羅することではなく、操作遅延の主因を外さないことです。
まず見る順番を固定します。一番目に実利用データ、二番目にモバイルの検証結果、三番目に診断欄、四番目に改善提案。 これ以外の順番で見る必要はありません。実利用データで INP が悪化していない URL は、代表 URL の選び方がずれている可能性があります。逆に実利用で悪く、検証結果で再現しないなら、端末性能差、通信条件差、ログイン後の状態差、同意バナーや外部スクリプトの発火条件を疑ってください。web.dev: Web Vitals の最適化 でも、実利用と検証の役割は分けて考えるべきだと整理されています。
実利用と検証の食い違いに対して、曖昧な言い方は不要です。実利用が悪く検証が良いなら、開発 PC を信じるべきではありません。利用者の環境を疑うべきです。 中価格帯 Android、4G 相当、タブを複数開いた状態、同意バナー表示あり、という条件で見直してください。逆に、検証だけ悪く実利用が健全なら、すぐに大規模改修へ入る必要はありません。例外は、問い合わせや申込の導線で、実機でも五回中三回以上遅れを体感できる場合です。このときは Search Console で赤が付いていなくても、先回りで直す価値があります。
PageSpeed Insightsの確認欄を絞る
PageSpeed Insights は情報量が多いため、読む欄を決めておかないと迷います。次のように割り切ると、判断が安定します。
見る欄 | そこで決めること | 直ちに採用する条件 | まだ保留でよい条件 |
|---|---|---|---|
実利用データ | 実際の利用環境で悪いか | INP が 200ms 超 | データ不足 |
モバイルの検証結果 | 再現の入口があるか | 同じ操作で毎回詰まる | デスクトップだけ遅い |
診断欄のメインスレッド作業 | JavaScript が主因か | 主な処理時間が目立つ | 他指標だけ悪い |
未使用 JavaScript や描画関連の指摘 | 何を疑うか | 同じテンプレートで共通部品が多い | その URL 固有の一時要因 |
改善提案一覧 | 調査の補助メモ | DevTools で再現できる | 再現できない |
ここで強く勧めたいのは、PageSpeed Insights の提案をそのまま開発依頼にしないことです。提案一覧は便利ですが、INP の主因ではない項目も多く混ざります。web.dev: クリティカル レンダリング パス や web.dev: Time to First Byte (TTFB) に関わる改善が必要な場面もありますが、INP だけが問題なら、まずは操作直後の処理に集中してください。LCP と CLS も同時に崩れているときだけ、複数指標を並行して扱います。その場合でも、一回の開発で渡す論点は三件前後に抑えるべきです。
DevToolsで遅い操作を五回以上再現して絞る
INP 改善が本当に前に進むのは、DevTools で「遅い操作」を再現できた瞬間です。Chrome DevTools は、遅い理由を推測する道具ではなく、重い処理を特定する道具です。 Chrome DevTools: Performance 機能 でも、実行中のページを記録しながらボトルネックを見つける手順が整理されています。INP の場面では、クリックから次の描画までの間に、イベント処理、スクリプト実行、スタイル計算、レイアウト、描画のどこが詰まっているかを見ます。
ここでの判断基準は曖昧にしないでください。同じ操作を最低五回、可能なら十回記録し、三回以上同じ箇所で詰まるなら修正対象とみなすべきです。 一回だけ遅いものは、通信の揺れ、初回キャッシュ、外部タグ、別タブの負荷が原因かもしれません。逆に、毎回 150ms を超えるイベント処理が出る、50ms 超のタスクが連続する、`Recalculate Style` と `Layout` が操作直後に何度も走る。この三つのどれかが再現するなら、実装に踏み込んで問題ありません。INP の改善は、平均値より再現性で判断したほうが失敗しにくい。
例外もあります。動画再生開始、地図の初回描画、重いグラフ描画のように、操作そのものが高負荷になりやすい機能では、完全な即時応答を求めるより、先に視覚的な反応を返す設計へ切り替えるほうが妥当です。web.dev: INP の最適化 でも、INP は非同期処理の完了全体ではなく、次の描画がどれだけ早く返るかに焦点があります。結果の取得が少し遅くても、押下状態、読み込み中の表示、開閉の先出しが速ければ、体感は改善できます。
長いタスクより操作直後の詰まりを必ず追う
DevTools を見ると、つい「長いタスク」だけに目が向きます。しかし、INP 改善で先に見るべきなのは、操作直後に詰まっている処理の流れです。一つの 300ms タスクが犯人とは限りません。80ms、90ms、70ms の処理が連続し、合計で次の描画が遅れている場面のほうが実務では多い。特に検索結果の絞り込み、候補サジェスト、フォームの入力補助、タブ切り替えでは、この型がよく出ます。
確認の手順も固定しておくべきです。
- モバイル表示に切り替え、対象ページ群の代表 URL を三本まで選ぶ。
- 遅いと感じる操作を二つまで決める。絞り込み、送信、アコーディオン、タブ切り替え、サジェスト表示のどれかに絞る。
- 同じ操作を五回以上記録し、毎回遅いのか、たまに遅いのかを分ける。
- 操作直後の `Event`、`Scripting`、`Recalculate Style`、`Layout` の並びを見る。
- 150ms 超のイベント処理、50ms 超の連続タスク、同一操作で三回以上再現するレイアウト再計算を優先候補にする。
- 外部タグ、同意管理、チャット、ヒートマップが同じ瞬間に動いていないかを確認する。
- 修正後は同じ端末条件、同じ回線条件、同じ操作回数で再記録する。
この七項目を外さなければ、開発側への依頼は「何となく重い」から「この操作でこの処理が詰まっている」へ変わります。そこまで落とせれば、改善の打率はかなり上がります。
改善対象はJavaScriptとUI部品から疑う
原因が見えたあとに、何から直すかでも差が出ます。INP で最初に疑うべきなのは、画像でもフォントでもなく、操作した瞬間に動く JavaScript と UI 部品です。 web.dev: INP の最適化 では、入力遅延、処理時間、描画遅延の三つを減らす方向が示されています。実務では、同期バリデーション、絞り込み条件の全件再描画、重い状態更新、タブ切り替え時の一括読み込み、同意バナーや解析タグの割り込みが主因になりやすい。だから、最初の改善対象は「押した瞬間に走る処理」に絞るべきです。
ここでありがちな誤りは、LCP の対策をそのまま持ち込むことです。画像圧縮や CDN 調整が不要とは言いませんが、INP の主因ではない場合が多い。クリック後に 220ms の配列整形が走っているのに、先に画像を軽くしても体感はほとんど変わりません。 逆に、フォーム入力のたびに全項目を同期検証している実装を、送信時検証や `blur` 時検証に変えるだけで、体感が大きく変わることがあります。月間 PV 10 万未満のサイトなら、こうした一部品の見直しだけで改善が成立する場合も少なくありません。
サーバー応答も無視できません。INP はフロントエンド指標として語られがちですが、クリック後に毎回 400ms を超える API 待ちがある画面は、利用者から見れば普通に遅いです。厳密には INP が測るのは次の描画までですが、描画前に待機表示すら出ない設計なら、操作遅延と区別できません。検索条件を一つ変えるたびに全件問い合わせを飛ばす、候補表示のたびに API を呼ぶ、送信前に重い整形を同期で実行する。この設計は避けてください。先読み、遅延送信、部分更新、結果キャッシュのいずれかへ寄せる必要があります。
改善対象の比較も、先に持っておくと判断が速くなります。
原因候補 | 先に直すべき条件 | 典型的な対処 | 先送りしてよい条件 | 注意点 |
|---|---|---|---|---|
重いイベント処理 | 150ms 超が三回以上再現 | 処理分割、事前計算、不要処理の削除 | 一回だけ遅い | 効果検証は同一操作で行う |
同期バリデーション | 入力のたびに全体検証 | `blur` 時や送信時へ寄せる | 入力頻度が少ない管理画面 | 入力補助の反応は維持する |
巨大な再描画 | タブや絞り込みで画面全体が更新 | 部分更新、表示領域の限定 | 一画面一機能で要素数が少ない | 見た目だけ変えても改善しない |
外部スクリプト | 操作直後に計測タグが割り込む | 発火条件の後ろ倒し、不要タグの停止 | 事後発火で影響が小さい | 事業部門と停止可否を確認する |
API 待ち | 一操作ごとに 300ms 超の問い合わせ | 遅延送信、キャッシュ、先読み | 更新頻度が低い固定画面 | 体感改善には先出し表示も必要 |
例外は、CLS や LCP が致命的に崩れているときです。Largest Contentful Paint (LCP) や Cumulative Layout Shift (CLS) まで同時に悪化しているなら、INP だけを切り離して直すと全体最適を外します。その場合だけは、共通ヘッダー、遅延読み込み、広告表示、DOM 構造まで含めて見直すべきです。ただし、それでも最初の一手は操作直後の詰まりを減らすことから外せません。
サイト規模別に優先策を変えて工数を抑える
INP 改善は、どのサイトでも同じ深さで進めるものではありません。月間 PV、導線の複雑さ、モバイル比率に応じて、診断の深さと実装の重さを変えるべきです。 規模に対して調査が重すぎると、施策が始まる前に疲弊します。逆に、大規模サイトで軽い見直しだけで済ませると、共通部品の問題を取りこぼします。
まず、月間 PV 10 万未満で、記事ページと問い合わせフォームが主導線のサイトです。この場合、最初にやるべきはフォーム周辺の操作遅延に絞った改善です。記事詳細を広く診断するより、フォーム入力、確認画面遷移、送信ボタン押下の三箇所に絞って追うほうが早い。例外は、カテゴリページや検索結果ページが主要流入になっているメディア型の構造です。この場合は一覧系を先に見ますが、それでも対象は一テンプレートで十分です。
次に、月間 PV 10 万〜100 万で、カテゴリ、検索、比較、資料請求の導線が混在するサイトです。ここでは、一覧系テンプレートと絞り込み UI を最優先にするべきです。 利用者は同じ訪問の中で複数回操作するため、記事詳細の一回の遅れより、一覧の反復操作の遅れのほうが離脱を生みやすい。特にモバイル比率が 60% を超えるなら、デスクトップで問題が軽く見えても判断を誤ります。モバイル前提で見てください。
月間 PV 100 万超で、React などのクライアント側処理が多いサイトでは、部品単位で監査を回すべきです。 共通ヘッダー、モーダル、タブ、カルーセル、検索候補、同意バナーのような横断部品は、テンプレート単位の観察だけでは追い切れません。ここまでの規模なら、四半期ごとに再描画の重い部品を棚卸しする運用が必要です。例外は、静的ページ中心で操作が少ない構造です。その場合は、テンプレート単位でも十分です。
さらに、モバイル流入が 70% を超え、海外流入や多言語展開があるサイトでは、中価格帯 Android 端末の実機を最優先にしてください。 デスクトップで再現しない遅延が、現場の利用端末では当たり前に起きます。この条件で開発用 Mac だけを信じるのは危険です。流入量と事業影響の判断が難しいときは、GA4のコンバージョン設定で迷わない 事業判断に効く設計とベストプラクティス を先に整え、施策前後で `到達率` `送信完了率` `回遊` を比較できる形にしてから進めるべきです。
規模別に推奨をまとめると、次の四つです。 月間 PV 10 万未満ならフォーム優先。 月間 PV 10 万〜100 万なら一覧と絞り込み優先。 月間 PV 100 万超なら共通 UI 部品の監査優先。 モバイル比率 70% 超なら実機優先。 この四本柱を外すと、改善は遠回りになります。
二週間で再計測まで回す進行表を先に置く
INP 改善は、いつまでも調査していると成果が出ません。最初の二週間で、対象ページ群の決定、仮説の絞り込み、重い操作の再現、修正候補の確定、再計測の準備まで進めるべきです。 半年単位の抽象的な議論にすると、LCP や CLS の話、組織内の役割分担、計測基盤の話が混ざり、INP の改善そのものが止まります。
進行表はこの形を勧めます。 1〜2日目: Search Console で不良群と改善余地ありの群を見て、対象ページ群を三つまで決める。 3〜4日目: PageSpeed Insights で代表 URL を確認し、仮説を二つまで絞る。 5〜7日目: DevTools と実機で同じ操作を五回以上記録し、再現性を確認する。 8〜10日目: 修正対象を `JavaScript` `UI 部品` `外部スクリプト` `API 待ち` の四類型に整理し、開発依頼は三件前後に絞る。 11〜14日目: 修正後の再記録、体感確認、Search Console の回復待ちに入る。
この順番であれば、現場がつまずきやすい誤りも避けやすくなります。避けるべき誤りは次の五つです。 Lighthouse の総合点だけで完了判定しない。 INP は総合点より操作遅延の再現結果で見るべきです。 不良 URL の件数だけで優先順位を決めない。 事業影響が近い導線を先に見るべきです。 PageSpeed Insights の提案を丸ごと渡さない。 仮説を二つまで絞るべきです。 一回だけ遅い操作を主犯扱いしない。 五回以上の再現で共通パターンを取るべきです。 修正後に Search Console だけ見て終えない。 DevTools と実機の即時確認を先に行うべきです。
最後に、今日やることを三つに絞ります。Search Console で最優先のページ群を一つ決める。代表 URL を二本選ぶ。遅い操作を一つだけ決めて、明日までに五回記録する。 ここまで進めれば、INP 改善は「何となく速くする話」ではなく、操作遅延を根拠付きで削る実務に変わります。最初の一歩で迷うなら、ツールを増やすのではなく、順番を固定してください。