Core Web Vitals入門（INPもやさしく）
Core Web Vitals（コアウェブバイタル）は、「表示が早い」「反応が良い」「ガタつかない」を実ユーザーのデータで測る指標セットです。INP（反応の良さ）・LCP（読み込み体感）・CLS（見た目の安定）を、基準値・合否の仕組み・計測方法・改善の優先順位まで、やさしく整理します。
- Core Web Vitalsとは？（まず結論）
- 3つの指標をやさしく説明（INP/LCP/CLS）
- 合否の仕組み：フィールドデータ（CrUX）と75パーセンタイル
- 基準値（Good / Needs improvement / Poor）早見表
- 計測ツールの使い分け（PSI / Search Console / Lighthouse / CrUX）
- 改善の優先順位（迷ったらこの順）
- 打ち手の例：INPを改善する（やさしく）
- 打ち手の例：LCPを改善する
- 打ち手の例：CLSを改善する
- よくある誤解（スコア100を目指しすぎない）
- 最初のチェックリスト（30分でOK）
- FAQ
- まとめ：まずは“合格ライン”を安定させる
Core Web Vitalsとは？（まず結論）
Core Web Vitals（コアウェブバイタル）は、Webページの体験を「実ユーザーのデータ」で測る重要指標セットです。 3つの指標で、次の体験を見ています。
- LCP：主要コンテンツが表示される速さ（読み込み体感）
- INP：クリックなどの操作に対する反応の良さ（体感のサクサク感）
- CLS：表示中のガタつきが少ないか（見た目の安定）
GoogleはCore Web Vitalsの達成を推奨しており、検索の「ページ体験」を理解するうえでも基礎になります。
結論：まずは「合格ライン（Good）を安定して満たす」ことが最優先です。
点数ゲームではなく、ユーザーが困らない状態を作るのが目的です。
3つの指標をやさしく説明（INP/LCP/CLS）
1) LCP：読み込み体感（“メインが出るまで”）
LCP（Largest Contentful Paint）は、画面の中で「メインっぽい大きな要素」（ヒーロー画像や見出しブロックなど）が 表示されるまでの時間です。「ちゃんと読める状態になるまで」の体感に近い指標です。
2) INP：反応の良さ（“押したのに反応しない”を減らす）
INP（Interaction to Next Paint）は、クリック/タップ/キー入力などの操作をしてから、 画面の更新（次の描画）が行われるまでの遅れを測ります。 ざっくり言うと、「操作してから反応するまで」です。
ブログでも、メニューの開閉、関連記事のスライダー、検索ボックス、フォーム、広告スクリプトなどで重くなり、 “押したのに固まる”が起きやすいので要注意です。
3) CLS：ガタつき（“読もうとしたらズレた”を減らす）
CLS（Cumulative Layout Shift）は、読み込み中に要素が後から入ってきてレイアウトがズレる量を測ります。 画像や広告枠、埋め込み、フォントの読み込みなどが原因になりがちです。
合否の仕組み：フィールドデータ（CrUX）と75パーセンタイル
Core Web Vitalsの評価で大事なのは、ラボ（テスト）ではなくフィールド（実ユーザー）が基準になることです。 PageSpeed InsightsやSearch ConsoleのCore Web Vitalsレポートは、主にChromeの実ユーザーデータ（CrUX）に基づきます。
- 期間：過去28日のローリング集計（28日分が常に更新されるイメージ）
- 判定：各指標の75パーセンタイル（p75）が「Good」閾値を満たすか
- 合否：INP/LCP/CLSの3つすべてがGoodならPass（十分なデータがある場合）
p75って？：「75%のユーザーがこの値以下」になるラインです。
一部の人だけ速いのではなく、多くの人が快適を目指す考え方です。
基準値（Good / Needs improvement / Poor）早見表
| 指標 | Good（合格） | Needs improvement（改善が必要） | Poor（不良） |
|---|---|---|---|
| LCP | 2.5秒以内 | 2.5〜4.0秒 | 4.0秒超 |
| INP | 200ms以内 | 200〜500ms | 500ms超 |
| CLS | 0.1以内 | 0.1〜0.25 | 0.25超 |
計測ツールの使い分け（PSI / Search Console / Lighthouse / CrUX）
迷いやすいので、役割で分けるとスムーズです。
| ツール | 得意 | 見るべき場面 |
|---|---|---|
| PageSpeed Insights | 1URLを深掘り（フィールド＋ラボ） | 問題ページの「現状→原因→打ち手」を詰める |
| Search Console | サイト全体の問題URL群を把握 | どのURL群を優先するか決める（Poorの塊を潰す） |
| Lighthouse（ラボ） | 原因特定・再現テスト | 修正前後で同条件比較、重いリソースの特定 |
| CrUX（API/可視化） | 実ユーザーデータの分析（集計の理解） | フィールドの傾向を詳しく見る（URL/オリジン） |
改善の優先順位（迷ったらこの順）
- Search Consoleで「Poor」URL群を特定（影響の大きい塊から）
- PSIで当該ページを計測し、フィールドでFailの指標を確認
- LCP → INP → CLSの順に、影響の大きい原因から直す
- 改善後は再計測（ラボ）＋数週間のフィールド反映を待って傾向を見る（28日集計のため）
打ち手の例：INPを改善する（やさしく）
INPが悪いときの原因は、だいたい「JavaScriptが忙しすぎる」です。 クリックした瞬間に、ブラウザが他の重い処理で手一杯だと反応が遅れます。
INP改善のよくある原因
- 重いスクリプト：多機能なUIライブラリ、アニメーション、計測タグの増殖
- サードパーティ：広告、埋め込み、チャット、ヒートマップなど
- 長いタスク：1回の処理が長く、メインスレッドが塞がる
まず効く“現場の3手”
- タグ棚卸し：本当に必要な外部タグだけに減らす（特にブログテンプレ共通）
- 遅延ロード：ファーストビューに不要なJSは後から読み込む
- 重い処理を分割：長いタスクを小さくする（UI反応を優先）
INPのコツ：「反応しない瞬間」を減らす指標です。
まずは共通テンプレに入っている外部スクリプトを疑うと、改善が早いことが多いです。
打ち手の例：LCPを改善する
LCPは「メインの表示が遅い」問題なので、原因は次のどれかに偏りがちです。
- 画像が重い：ヒーロー画像/OGP相当の大きな画像が未最適化
- CSS/JSで描画が止まる：レンダリングブロック
- サーバー応答が遅い：TTFBが遅く、全体が後ろ倒し
代表的な打ち手
- ヒーロー画像を適正サイズにし、WebP/AVIFや圧縮で軽量化
- 不要CSS削減、重要CSSの最小化、JSのdefer/async
- キャッシュ/CDN、重いプラグイン整理、DB負荷の削減
打ち手の例：CLSを改善する
CLSは“ガタつき”なので、原因の多くは後から要素が増えることです。
よくある原因
- 画像・広告枠のサイズが未指定（読み込み後に押し広げる）
- 埋め込み（SNS/動画）を後から挿入してレイアウトが動く
- フォント読み込みで文字幅が変わる
代表的な打ち手
- 画像/広告枠にwidth/heightや比率でスペース確保
- 後挿し要素は、先に枠だけ確保する（プレースホルダー）
- フォントの読み込み方を見直し（見た目が飛びにくい設定）
よくある誤解（スコア100を目指しすぎない）
- 誤解：ラボが良い＝実ユーザーも良い → 現実：合否はフィールド（実ユーザー）基準です。
- 誤解：全ページで満点が必要 → 現実：まずはPoorの塊と主要流入ページから。
- 誤解：改善したらすぐ反映 → 現実：フィールドは28日集計なので、傾向が動くまで時間がかかります。
最初のチェックリスト（30分でOK）
- Search ConsoleでCore Web Vitalsレポートを開き、PoorのURL群を把握
- Poor群の代表URLをPSIで計測し、Failの指標（INP/LCP/CLS）を特定
- ブログの共通テンプレにある外部タグ（広告/計測/埋め込み）を棚卸し
- ファーストビューの大きな画像を最適化（サイズ/形式/圧縮）
- 画像/広告枠のサイズ確保（CLS対策）
FAQ
Q1. INPとTBTは何が違う？
INPは実ユーザーの「反応の遅れ」（フィールド指標）を中心に見ます。 一方、TBTはLighthouseなどのラボ指標で、「メインスレッドがどれだけ塞がっているか」を疑うヒントになります。 まずはINP（結果）→TBTなどで原因を掘る、が分かりやすいです。
Q2. 新しいページはフィールドデータが出ません
フィールドデータは実ユーザーの十分な量がないと表示されないことがあります。 その場合はラボ（Lighthouse/PSI）で原因を先に潰しつつ、流入が増えるのを待ってフィールドで確認します。
Q3. まずはどれを合格させるべき？
迷ったらLCP→INP→CLSの順で、特に主要流入ページ（検索/SNS/広告の入口）を優先してください。 ただし、Search Consoleで「このURL群はCLSが原因でPoor」など、明確に出ているならその指標からでOKです。
まとめ：まずは“合格ライン”を安定させる
- Core Web VitalsはINP（反応）/ LCP（読み込み）/ CLS（安定）の3点セット
- 合否はフィールド（実ユーザー）のp75で判断され、3つ全部GoodでPass
- 改善は「Search Consoleで範囲特定→PSIで深掘り→原因の大きい順に修正」が最短
- まずは満点より、主要ページで合格を安定させるのが現実的