"体感速度"最適化
INP改善でコンバージョン率を最大化する方法
ページは表示されたのに、「ボタンを押しても反応が遅い」。
この"操作のもたつき"は、コンバージョン率に直結します。
2024年3月、GoogleはCore Web Vitalsの指標として INP（Interaction to Next Paint）を正式採用しました。 これはユーザーの操作に対する応答性を測る指標です。
本記事ではGoogle公式ドキュメントに基づき、 INPの正しい理解から、実務で使える改善アプローチ、 そしてCVR最大化につながる考え方までを体系的に整理します。
INPとは何か？
INP（Interaction to Next Paint）とは、 ユーザーがクリック・タップ・キー入力などを行ってから、 画面が次に更新（描画）されるまでの時間を測る指標です。
参照： Google Web.dev「Interaction to Next Paint (INP)」以前はFID（First Input Delay）が使用されていましたが、 FIDは「最初の入力」しか測定しませんでした。 INPはページ滞在中のほぼすべてのインタラクションを対象とし、 実際の体感により近い評価が可能です。
参照： Google Developers「INP will replace FID」つまりINPは「表示の速さ」ではなく、 "操作に対する反応の速さ"を測る指標です。
なぜCVRに影響するのか
操作に対する反応が遅いと、ユーザーは無意識にストレスや不安を感じます。 特にコンバージョン直前の操作で遅延が起きると、離脱につながります。
影響が大きい代表的な場面
- フォーム送信ボタン
- カート追加ボタン
- モーダル表示
- メニュー展開
架空事例：ECサイトの場合
あるECサイトでは、「カートに入れる」ボタン押下後、 0.6秒の遅延が発生していました。
ユーザーは反応がないと感じて2回クリックし、 結果的に二重追加エラーが発生。問い合わせ増加とCVR低下が起きていました。
INPを200ms台まで改善したところ、二重クリック率が減少し、 CVRが約8%改善しました。
「押したのに反応しない」体験は、CVR低下の直接要因になります。
良好とされる基準値
Googleは以下の基準を示しています。
目標は200ms以下。 体感的には「押した瞬間に反応する」レベルが理想です。
INPが悪化する主な原因
- 長時間実行されるJavaScript（Long Tasks）
- 重いイベントリスナー処理
- 大規模なDOM更新
- 不要な同期処理
特に「メインスレッドを占有する処理」があると、 入力イベントが待たされ、INPが悪化します。
具体的な改善方法
初期表示に不要なコードを遅延読み込みし、 インタラクション時の負荷を軽減します。
50ms以上のタスクは分割し、 requestIdleCallbackやWeb Workerの活用を検討します。
レイアウトスラッシングを回避し、 DOM操作はバッチ処理でまとめて実行します。
スピナー表示やボタン状態変更など、 即時フィードバックを与えることで体感速度を向上させます。
計測と検証方法
INPは以下のツールで確認できます。
- PageSpeed Insights
- Chrome DevTools（Performanceパネル）
- Search Console（Core Web Vitalsレポート）
ラボデータだけでなく、実ユーザーデータ（CrUX）で確認することが重要です。
まとめ
INP改善は単なる技術最適化ではなく、 操作体験の改善＝信頼の獲得です。
- 目標は200ms以下
- 長時間タスクを分割する
- JavaScript負荷を削減する
- 実ユーザーデータで検証する
表示速度だけでは足りない。
「押した瞬間に反応する」体験が、コンバージョンを最大化します。
