Core Web Vitalsの「応答性」を測ってきたFID（First Input Delay）は、2024年3月にINP（Interaction to Next Paint）へ正式に置き換わりました。これにより、最初の1回だけでなくページ滞在中の全操作の遅さが評価される時代に。採用サイトのフォーム/タブ/アコーディオンの“もたつき”が、より厳密に点検されます。
1. なぜFIDからINPになったのか
FIDは「初回入力までの遅延」を測るだけでした。実際の不満は、入力中のバリデーションやタブ切替、モーダル開閉など、その後の操作にも多く潜みます。INPはこれらすべての主要操作の応答を観測し、概ね最も遅い体験を代表値として扱います。
“INP assesses a page’s overall responsiveness by observing the latency of all interactions… the longest observed interaction is reported.”
Interaction to Next Paint (web.dev)
Chrome/Googleは2024年3月12日にINPをCore Web Vitalsへ昇格、FIDは段階的に非推奨に。開発ツールでのFIDサポートも終了スケジュールが告知されています。
“INP will officially become a Core Web Vital and replace FID on March 12.”
web.dev – INP becomes a Core Web Vital
2. INPの合格ラインと判定の見方
- 良好：≤ 200ms
- 要改善：200–500ms
- 不十分：> 500ms
Core Web Vitalsの判定は75パーセンタイル（p75）で行われます（CrUX/PSI）。つまり、75%の実ユーザー体験でINP 200ms以下を目標にする必要があります。
“An INP below or at 200 ms means good responsiveness… measured at the 75th percentile.”
web.dev – Optimize INP
3. 採用サイトで影響が大きい箇所
- 応募フォーム：入力ごとの同期バリデーション、住所補完、ファイル添付の前処理
- タブ/アコーディオン：開閉時の大量DOM再計算、アニメーションのレイアウト負荷
- メディア/フォント：画像・Webフォントの初期描画遅延が後続操作にも波及
- サードパーティ：チャット、ABテスト、解析タグのイベントフックや同期実行
これらの多くは長時間タスク（Long Task）やメインスレッド過負荷が原因。まずは長い処理を細かく分割し、不要なJSを読み込まない/遅延させる方針が効きます。:contentReference[oaicite:9]{index=9}
4. 計測フロー：フィールド→ラボの二段構え
- PSI/CrUXで実測（p75）：モバイル/デスクトップのINP分布とp75を確認
- DevTools/Lighthouseで再現：遅い操作の録画、Long Tasksとイベントハンドラを特定
- ステージングで修正→本番：タグやCDN設定も含め現実条件で検証、週次でPSI定点観測
“Ideally, your journey in optimizing INP will start with field data… then test in the lab to identify slow interactions.”
web.dev – Optimize INP
5. 優先修正リスト（採用サイト向け）
5-1. フォームの反応を軽くする
- 入力ごとの重い検証はblur/changeに集約、住所補完は非同期＋スロットリング
- ファイル添付のウイルス/拡張子チェックは非同期化、進捗UIで体感を改善
- DOM更新は差分最小化（仮想DOM or 原始的にinnerHTML置換を避ける）
5-2. JSの長時間タスクを分割
- 50ms超のタスクを分割（requestIdleCallbackやsetTimeout(0)で小分け）
- 巨大バンドルをページ単位でコード分割、必要箇所のみ遅延ロード
- チャット/AB/解析は応募ページのみ発火
5-3. 初期描画の負荷を減らす
- ヒーロー画像に
fetchpriority="high"、寸法指定、AVIF/WebP化 - Webフォントはサブセット＋
font-display: swap＋preload - カルーセルは初期スライドのみ描画、残りはIntersectionObserverで遅延
これらはLCP/CLSの改善とも連動し、総合的な合格率を押し上げます。
6. 成功事例に学ぶ：長時間タスクの「分割」が鍵
大手不動産プラットフォームでは、長時間タスクを細かく分割し、async/awaitでyield point（処理の小休止）を作ることでINPを大幅に改善しました。採用サイトでも、検索やフィルタ、住所補完などに同じ技法を適用できます。
“By optimizing long tasks… improvements were achieved in many slow interactions affecting INP, employing
async/awaitto create yield points.”
Case study – QuintoAndar
7. よくある質問（FAQ）
Q. 目標値は？
モバイル/デスクトップともにp75でINP≤200msを目指します。
Q. FIDのモニタリングは完全終了？
INPへの正式置換後、Chromeのツール側サポートは段階的に終了しました。今後はINP中心での運用へ。
Q. まずは何から直す？
遅い操作を一つ特定し、その操作のイベント処理を分割・非同期化するのが最短です。次に、ヒーロー画像の優先読込とフォントのswapで初期描画を底上げします。
参考（一次情報の抜粋）
“INP will officially become a Core Web Vital and replace FID on March 12.”
web.dev
“Chrome is officially deprecating support for FID… developers will have until September 9, 2024 to transition.”
web.dev
“INP assesses… by observing the latency of all interactions… the longest interaction is reported.”
web.dev
“For this reason we conclude a 200 ms is a reasonable ‘good’ threshold… greater than 500 ms is ‘poor’.”
web.dev
“PSI reports the 75th percentile for all metrics.”
Google Developers
コメント