応募フォームが押しても反応しない、タブ切り替えがワンテンポ遅れる──この「もたつき」を数値で捉える指標が INP（Interaction to Next Paint） です。本稿では、INPの意味・基準・計測方法から、採用サイト特有の“重くなりがちポイント”の直し方までを、実務でそのまま使える形でまとめました。
INPとは：しきい値・評価の仕組み
INPは「ユーザーの操作に対して、画面が次に描画されるまでの応答の遅さ」を観測する指標です。ページ滞在中の複数の操作（クリック・タップ・入力など）のうち、概ね最も遅かった体験を代表値として採用します。
“INP observes the latency of all interactions a user has made with the page, and reports a single value…”
— How to Optimize INP – web.dev
評価の目安（モバイル/デスクトップ別に75パーセンタイルで判定）は次の通りです。
- 良好：200ms以下
- 要改善：200ms超〜500ms以下
- 不十分：500ms超
“An INP below or at 200 milliseconds means a page has good responsiveness…”
— Interaction to Next Paint (INP) – web.dev
なお、INPは2024年3月12日にCore Web Vitalsへ正式採用され、FIDは置き換えられました。
“INP will officially become a Core Web Vital and replace FID on March 12…”
— INP becomes a Core Web Vital – web.dev
採用サイトでINPが悪化しやすい要因
採用サイトは「入力や切替」が多く、以下の要因でINPが悪化しがちです。
- フォームの同期バリデーション：入力の度に重い処理（正規表現・住所補完・DOM再計算）が走る
- 無駄に大きいバンドル：UIライブラリ・日付/住所/マスク系プラグインを丸ごと読み込み
- カルーセル/モーダル/アコーディオンのリフロー：開閉や切替で大量のレイアウト再計算
- Webフォント・巨大画像：初回描画が遅れ、次描画タイミングが詰まる
- 外部タグ：チャット/ABテスト/解析のイベントハンドラが主スレッドを塞ぐ
実測のやり方（PSI/Chrome拡張/CrUX）と読み方
まずは「現実のユーザー体験」を表すフィールドデータで把握します。PageSpeed Insights（PSI）はCrUX（Chrome UX Report）のデータから75パーセンタイルで判定します。
“PSI reports the 75th percentile for all metrics.”
— About PageSpeed Insights – Google Developers
おすすめ計測フロー
- PSI（モバイル/デスクトップ）でフィールド値を確認
- 同ページをChrome拡張「Web Vitals」やDevTools Performanceで操作し、遅い操作を特定
- ステージングで改修→PSIの「実測（フィールド）」は28日移動窓のため、ラボ値（Lighthouse/DevTools）で即時効果を確認
改善チェックリスト（優先度順）
1. 送信/開閉/タブ切替の遅延解消
- イベントハンドラの軽量化：入力ごとではなくblur/changeで検証／重い処理はrequestIdleCallbackやsetTimeoutで後回し
- 長いタスクの分割：Taskが50ms超なら分割（DevToolsでLong Taskを確認）
- 非同期化：住所補完・郵便番号変換・重い整形は非同期＋スケジューリング
- DOM最小更新：開閉UIはaria属性と高さのトグルのみで再計算を抑制
2. 画像/フォントの初期描画最適化
- ヒーロー画像：fetchpriority=”high”付与、width/height明示、WebP/AVIF化
- 遅延読込：下層はloading=”lazy”、カルーセルは初期スライドのみ読み込み
- Webフォント：サブセット化＋font-display: swap＋先読み（preload）
- アイコン：フォントからSVGスプライトへ移行
3. JS分割・遅延・不要ライブラリ削減
- コード分割：職種検索・地図・日付ピッカーなどは遅延ロード
- 使用箇所のみimport：ユーティリティ/マスクは必要関数だけ取り込み
- third-party整理：チャットやABツールは「必要ページのみ」で発火
4. サーバー/キャッシュ/CDN
- HTTP/2/3 + 圧縮（Brotli優先）
- キャッシュ戦略：静的資産は長期キャッシュ＋ファイル名にハッシュ
- 画像CDN：サイズ自動最適化・フォーマット変換・リージョン配信
LCP/CLSとの関係（総合での合格戦略）
INPだけ良くても、LCP（最大コンテンツ描画）/CLS（レイアウトずれ）で落ちると総合評価は上がりません。特に採用サイトは写真・フォント・埋め込みが多く、LCP/CLSが悪化しやすい構造です。INP対策と同時に、以下を必須セットで実施しましょう。
- LCP：ヒーロー画像の先読み、クリティカルCSSの抽出、初期JSの削減
- CLS：画像/広告/埋め込みに寸法を明示、フォントのFOUT対策
事前検証とリリーステスト（実機＋3キャリア）
INPは「実際の操作」に強く依存します。下記の実機テストを標準化すると、事故が激減します。
- 端末：iPhone標準機種＋Androidミドルレンジ
- 回線：4G/5G/Wi-Fiでの再現テスト
- 操作：応募フォーム（各ステップ）、タブ切替、FAQ開閉、写真ギャラリー、地図
- 計測：DevTools Performanceで操作区間を記録し、Long Taskとイベント処理を突き止める
よくある質問（FAQ）
Q. 合格ラインはどの値で見ればいい？
モバイル/デスクトップそれぞれの75パーセンタイルで、INPが200ms以下を目指します（PSIのフィールド値を基準に）。
Q. INPはどんな操作が対象？
クリック/タップ/キーボード入力などの主要な操作が対象です。ページ滞在中の複数操作を観測し、遅い体験が代表値として報告されます。
Q. FIDとの違いは？
FIDは「最初の入力の遅延」だけでしたが、INPはページ全体の操作を評価します。2024年3月に正式置換されました。
参考（一次情報の抜粋）
“INP will officially become a Core Web Vital and replace FID on March 12…”
— INP becomes a Core Web Vital – web.dev
“An INP below or at 200 milliseconds means a page has good responsiveness…”
— Interaction to Next Paint (INP) – web.dev
“PSI reports the 75th percentile for all metrics.”
— About PageSpeed Insights – Google Developers
“INP observes the latency of all interactions a user has made with the page…”
— How to Optimize INP – web.dev
次に読む（内部リンク）
この記事は、実案件の運用で増えがちな「フォームが重い」「切替が引っかかる」を、計測→原因特定→最短で直すための地図として設計しました。迷ったらまず、遅い操作を一つ特定し、その操作に直接効く対策から着手してください。体感は、そこから一気に変わります。
コメント