
2024年にGoogleのCore Web Vitals(CWV)にInteraction to Next Paint(INP)が正式採用され、ページのユーザー体験(UX)がSEOの重要な評価基準となりました。
INPは、ユーザーのインタラクション(クリック、タップ、キー入力など)から次の画面描画までの時間を測定し、良好な目安は200ms未満です。単一の「遅い操作」が全体の評価を下げるため、診断から修正、検証までを体系的に進める必要があります。
本記事では、実践可能な最適化手法をテンプレート化して解説します。
詳細なSEOの基本を知りたい方は、お気軽にお問い合わせください。
INPの理解:なぜ“体感”と相関するのか
INP(Interaction to Next Paint)は、ページ訪問中の最も遅いインタラクションの遅延時間を測定します(外れ値を除外)。
ユーザーの「体感速度」に直結し、遅延が長いと直帰率やエンゲージメント低下を招きます。
測定は以下のツールで可能です。
-
CrUX(Chrome User Experience Report):実ユーザーデータを基にした評価。
-
Lighthouse:シミュレーション環境での診断。
しきい値(Google for Developersによる):
-
良好:200ms未満
-
要改善:200~500ms
-
不良:500ms超
※しきい値とは:ある条件を満たすかどうかの「境界線となる値」
マーケティングで言うところの顧客が製品を購入するかどうかを判断する基準となる値
INPが高いと、ユーザーが「サイトが重い」と感じ、離脱リスクが高まります。特に、メニューや検索ボタン、CTA(Call to Action)の反応速度が重要です。
ボトルネック別・診断フロー
INPの悪化原因を特定するには、以下のボトルネック(ビジネスにおいては、生産性や業務効率を妨げている工程や原因を意味)を診断します。
長タスク(>50ms)の検出
長タスク(50msを超える処理)は、ブラウザのメインスレッドをブロックし、INPを悪化させます。
Performance Profiler(Chrome DevTools)で以下の手順で確認できます。
-
ページをDevToolsで開き、「Performance」タブを選択。
-
インタラクション(クリック、タップ)を記録し、長タスクを特定。
-
タスクの内訳(例:JavaScript実行、スタイル計算)を分析。
レンダーブロック(大JS/CSS・同期スクリプト)
レンダリングを阻害するリソースがINPに影響します。
以下を確認してください。
-
大きなJavaScript/CSSファイルの読み込み。
-
同期スクリプト(<script>タグにdeferやasyncがない)。
-
解決策:スクリプトを非同期化(defer/async)または分割。
入力処理の遅延(イベントハンドラの重さ・サードパーティ)
重いイベントハンドラやサードパーティスクリプトが遅延を引き起こします。
-
チェック:onclickやonchangeなどのハンドラが複雑な処理を含んでいないか。
-
対策:サードパーティスクリプト(例:広告、トラッキング)の遅延読み込みや軽量化。
メディアの遅延(巨大画像・動画の初期化)
画像や動画の読み込みが遅いと、インタラクション後の描画が遅延します。
-
チェック:画像サイズが適切か、動画の初期化が重くないか。
-
対策:WebP/AVIF形式の採用、動画の遅延読み込み。
はてなブログでまず効く“即打ち”施策
ここでは、はてなブログユーザーが即実践できるINP改善施策を以下にまとめます。
-
不要ウィジェット・外部JSの削減
サイドバーのウィジェットや外部スクリプト(例:SNS埋め込み)を削除。
遅延読み込みは必須だが、入力直前の遅延は避ける(例:検索ボタンのJSは即読み込み)。 -
画像の最適化
画像をWebP/AVIF形式に変換、最大幅を1200px程度に圧縮。
<img fetchpriority="high">で重要画像を優先読み込み。 -
フォントの最適化
システムフォント(例:font-family: system-ui)を優先し、カスタムフォントはrel="preload"で事前読み込み。 -
タグマネージャーの最適化
Google Tag Managerの同時実行数を制限、発火条件を厳格化
(例:スクロール50%到達時)。 -
折りたたみ箇所のDEFER
非表示コンテンツ(例:コメント欄)のJSはdeferで遅延。
重要UI(メニュー、検索)は優先読み込み。
こちらの記事も参考にしてください。
コードレベル改善の具体(参考)
コードレベルでのINP改善は、以下のテンプレートを参考にしてみてください。
-
長タスク分割
// 重い処理を分割 function heavyTask() { const chunk = data.slice(0, 100); processChunk(chunk); if (data.length > 100) { setTimeout(() => heavyTask(data.slice(100)), 0); } } // アイドル時に実行 requestIdleCallback(heavyTask); -
イベントリスナの軽量化
// デリゲーションで効率化 document.body.addEventListener('click', (e) => { if (e.target.matches('.button')) { // 処理を簡潔に handleButtonClick(e.target); } }); -
スレッドオフロード
// Web Workerで重処理を隔離 const worker = new Worker('heavy-task.js'); worker.postMessage(data); worker.onmessage = (e) => { // 結果を処理 };
計測と継続した運用
INPの改善効果を測定し、継続的な運用を行うには以下を実施。
-
PageSpeed Insights/Lighthouse:シミュレーションでINPを診断。長タスクやレンダーブロックを特定。
-
GSCのCWVレポート:実ユーザーのINPデータを確認。「良好」比率をモニタリング。
-
CrUX:4週間単位で実ユーザーデータを分析。INP中央値が200ms未満かをチェック。
運用テンプレート(一例)
-
INPリスク表を作成
変更点
影響範囲
ロールバック手順
JS遅延読み込み
検索ボタン
元の<script>に戻す
画像WebP化
全ページ
元形式に復元
-
リリースごとにリスク表を更新し、問題発生時に迅速に対応。
チェックリスト
以下のチェックリストでINP最適化の確認ができます。
まとめ
INPはCore Web Vitalsの重要な指標であり、ユーザーの体感速度を左右します。今回の記事では紹介した実践可能な「即打ち施策」(不要JS削減、画像最適化、フォント調整)とコードレベルの改善(長タスク分割、イベントリスナ軽量化)を組み合わせ、INPを200ms未満に保ちましょう。
PageSpeed Insights、GSC、CrUXを活用した継続的な計測とチェックリストを用いた運用で、上位表示を目指せます。まずはPerformance Profilerで長タスクを診断し、改善をスタートしましょう!
関連記事