「INPってどこを見れば良いの？」「PageSpeed Insights（PSI）の数値が日によって違う…」——そんな迷いを解消するための手順特化ガイドです。PSIの画面で見る場所、INPの合格ライン、改善提案（Diagnostics）の優先度付け、開発フローへの組み込みまでを一気に整理します。
PSIの使い方：モバイル/デスクトップ切替・実測/ラボの違い
PSIは上部タブでモバイル/デスクトップを切替え、上段の「フィールドデータ（実測）」、下段の「ラボデータ（Lighthouse）」を並べて表示します。実務では、まずフィールドで現状を掴み、ラボで原因を特定する流れが効率的です。
“PSI reports the 75th percentile for all metrics.”
— About PageSpeed Insights
“Lab data and field data measure very different things.”
— Why lab and field data can be different (web.dev)
ポイントは実測＝CrUX（Chrome UX Report）に基づくこと。直近28日間のユーザー体験の分布（75パーセンタイル）で評価されるため、リリース直後は反映に時間差があります。
INPの見方：分布・75%ルール・合格基準
INPは「ユーザー操作から次の描画までの遅延」をページ滞在中の複数操作から評価し、概ね最も遅かった体験を代表値として報告します。合格基準は以下。
- 良好：200ms 以下
- 要改善：200〜500ms
- 不十分：500ms 超
“To provide a good user experience, websites should strive to have an INP of 200 ms or less… measure at the 75th percentile across mobile and desktop.”
— Optimize Interaction to Next Paint (web.dev)
“INP assesses a page’s overall responsiveness by observing the latency of all interactions (click, tap, keyboard).”
— Interaction to Next Paint (web.dev)
PSIの「フィールドデータ」枠では、INPの分布（Good/Needs improvement/Poorの割合）と、75パーセンタイル値（例：p75 INP = 220ms）を確認できます。
“For example… INP’s 75th percentile is 64ms, meaning 75% of INP experiences are faster than 64ms.”
— How to view CrUX data on PageSpeed Insights (Chrome for Developers)
改善提案（Diagnostics）の読み方：優先度付けのコツ
画面下部の「Opportunities」「Diagnostics」は、主にラボ側（Lighthouse）による改善ヒントです。INPに効く観点は次のとおり。
- Long tasks（50ms超の長いタスク）：JSの分割・遅延実行で短く区切る
- Main-thread work：入力/開閉/タブ切替に関与する処理を軽量化
- Render-blocking resources：初期JS/CSSの削減、critical CSS抽出
- Third-party：チャット/AB/解析タグを必要ページだけ発火
“Opportunities provide suggestions… the Diagnostics section lists additional guidance that developers can explore to further improve performance.”
— Lighthouse performance scoring
「LCP改善」「CLS改善」項目もINPに間接的に効くことが多いため、ヒーロー画像の優先読込（fetchpriority）や寸法指定などは同時に実装しましょう。
“To improve LCP, you have to look at the entire loading process.”
— Optimize Largest Contentful Paint (web.dev)
開発フローへの組み込み：ステージング/本番/定点観測
- ステージングでラボ検証：DevTools/Lighthouseで遅い操作を再現し、Long Taskやイベント処理のボトルネックを記録
- 本番リリース：タグやCDN条件を含めた実環境でA/Bの差分チェック
- 定点観測：PSIでモバイル/デスクトップのフィールド値（p75）を週次確認。28日窓のため、短期はラボ、長期は実測で追う
“Lighthouse can synthetically measure… Core Web Vitals metrics… for lab testing.”
— Optimizing Web Vitals using Lighthouse (web.dev)
よくあるハマりどころ：Cookie同意・A/Bツール・広告タグ
- Cookie同意バナー：DOMを大きく再描画する設計は避け、非同期＆最小差分更新に
- A/Bテスト：全ページ常時の同期実行は避け、対象ページのみ遅延読み込み
- 広告/計測タグ：
defer/async＋自己ホスト化の検討、発火条件を厳密化
“Even if the LCP resource is discoverable… it may not start loading as early as the first resource. Optimize the priority the resource is given.”
— Optimize LCP (web.dev)
最短フロー（チェックリスト）
- PSIでモバイル/デスクトップのp75 INPと分布を確認（実測）
- Lighthouse（ラボ）でLong Task/Third-party/Render-blockingを特定
- フォームの入力・開閉・タブ切替の操作遅延から順番に軽量化
- ヒーローのfetchpriority、画像の寸法、フォントの
font-displayで初期描画を改善 - 1〜2週後にPSIでフィールド値の改善を追認（定点観測）
参考（一次情報の抜粋）
“PSI reports the 75th percentile for all metrics.”
— About PageSpeed Insights
“To provide a good user experience, websites should strive to have an INP of 200 ms or less… measured at the 75th percentile.”
— Optimize INP (web.dev)
“INP assesses responsiveness by observing the latency of all interactions.”
— Interaction to Next Paint (web.dev)
“Lab data and field data measure very different things.”
— Lab vs Field (web.dev)
“How to view Chrome UX Report data on PageSpeed Insights… INP’s 75th percentile is 64ms …”
— CrUX on PSI (Chrome for Developers)
コメント