Core Web Vitals 実践対策：LCP／INP／CLS の診断と優先順位
1. 3 指標がそれぞれ何を見るか：まず切り分けてから手を動かす
多くのチームはいきなり Lighthouse を回し、赤いバツ印を見てやみくもに直し始めます。まず各指標が何を測っているのかを押さえないと、正しい対処はできません。
| 指標 | 何を測るか | 合格ライン | よくある原因 |
|---|---|---|---|
| LCP 最大コンテンツ描画 | ファーストビューの最大要素が読み込み完了するまでの時間 | 2.5秒以内 | ファーストビュー画像が大きすぎる、フォントのブロック、サーバー応答が遅い |
| INP 操作から次の描画まで | ユーザーがクリックした後の画面応答の遅れ | ≤ 200ミリ秒 | メインスレッドの長いタスク、JS のサイズ過大、サードパーティスクリプト |
| CLS 累積レイアウトシフト | ページ読み込み中に要素がどれだけ動くか | 0.1以下 | 画像に幅と高さがない、広告枠にプレースホルダーがない、フォントの切り替え |
判定は必ず 75 パーセンタイルで行います。100 人の訪問者のうち上位 75 人が基準を満たして初めて合格です。平均値や中央値に意味はありません。CrUX データは Search Console の体験レポートで確認できます。Google のランキングシグナルが使うのと同じデータです。
さらに 3 指標は互いに影響し合う点にも注意が必要です。画像を圧縮すれば LCP は下がりますが、画像の lazy load の設定を誤ると、かえって LCP 要素が 2 フレーム目にずれ込みます。フォントの preload は LCP を下げますが、preload するフォントが多すぎるとネットワークリクエストを圧迫し INP に悪影響します。1 項目を変更したら 14 日待って実ユーザーデータを確認し、連続して変更しないでください。
2. LCP の対策：効果が最大なので最初にやる
LCP は通常、3 指標の改善効果の 50％ 以上を占めます。4 つの段階で構成されるので、まずどこで詰まっているかを見ます。
| LCP の段階 | 診断ツール | よくあるボトルネック | 対策 |
|---|---|---|---|
| TTFB サーバー応答 | WebPageTest ウォーターフォール | PHP のレンダリングが遅い、CDN を経由していない | CDN エッジキャッシュ、PHP のアップグレード |
| リソース読み込み | Chrome DevTools パフォーマンス | ファーストビュー画像が未圧縮、preload していない | WebP／AVIF、重要な画像を preload |
| リソースのレンダリング | Lighthouse の改善提案 | フォントがレンダリングをブロック | font-display: swap + preload |
| クライアントサイドレンダリング | Trace パフォーマンスパネル | SPA は JS のダウンロード完了まで描画しない | SSR またはスケルトン画面 |
事例：B2B 製造業サイトのファーストビューにある製品画像が1.8MBの未圧縮で、TTFBは正常なのにLCPが4.2秒で止まっていた。画像をWebPに変換して320KBまで圧縮し、fetchpriority=”high”を付けたところ、LCPは1週間で1.9秒に短縮。変更したのはimgタグ1つだけで、サーバー設定は一切触っていない。
CDNのノード選定とキャッシュ戦略はTTFBに直結します。詳しくはCDNによるグローバル高速化をご覧ください。多言語サイトの画像ローカライズは多言語サイトのグラフ処理とあわせて検討する必要があります。
三、INPの修正：最も手間がかかるが省略できない
INPは2024年3月にFIDを置き換えた新しい指標で、ユーザーの操作から画面が実際に反応するまでの遅延を測ります。問題がJSバンドル全体に散らばっているため、LCPより修正が難しい指標です。
| 問題 | 診断方法 | 対策 | 期待できる効果 |
|---|---|---|---|
| メインスレッドの長いタスクが50ms超 | Performanceパネルで長いタスクを確認 | コード分割、Web Worker | INPが100〜200ミリ秒改善 |
| サードパーティスクリプトのブロック | Coverageパネルで割合を確認 | 遅延読み込み、async/defer | INPが50〜150ミリ秒改善 |
| イベントコールバックが重い | コールスタックで時間のかかる関数を確認 | デバウンス・スロットリング、コールバックの分割 | INPが30〜80ミリ秒改善 |
| レンダリングを妨げるリソース | Lighthouseで未使用のCSS/JSを確認 | クリティカルCSSのインライン化、非クリティカルの遅延 | INPが50〜100ミリ秒改善 |
意外なポイント：INPの悪化は自分のコードだけが原因とは限りません。B2BサイトにはLinkedInピクセル、HubSpotのフォームプラグイン、チャットサポートのスクリプトが埋め込まれていることが多く、この3つだけでメインスレッドを300ミリ秒以上ブロックすることがあります。まずサードパーティスクリプトを読み込み優先度順に整理するほうが、業務コードを直すより早く効果が出ます。
四、CLSの修正：対応すればすぐ安定する取り組みやすい改善
CLSは3指標の中で最も修正しやすいものです。CLSの問題の90%は2つの原因に集約されます。画像に幅と高さが指定されていない、広告や埋め込みコンテンツにプレースホルダーがない。
| CLSの主な原因 | 判断方法 | 対策 |
|---|---|---|
| 画像にwidth/heightがない | DevToolsでレイアウトシフトを確認 | imgタグにwidth/height + aspect-ratioを追加 |
| フォント切り替え時のちらつき | FOIT/FOUTの発生 | font-display: swap + size-adjust |
| 広告・埋め込みにプレースホルダーがない | 広告の読み込み後にコンテンツが押し出される | 固定高さのコンテナを確保 |
| 動的に挿入されるバナー | 上部の通知バーが表示される | スペースを確保し、コンテンツを押し出さない |
事例2：海外展開するSaaSサイトのブログでCLSが長期間0.35だった。原因は記事上部の「ニュースレター登録」バナーがJSの読み込み後に挿入され、記事全体を120ピクセル下に押し出していたこと。バナーをサーバーサイドレンダリングに変更し、120pxのプレースホルダーを確保したところ、CLSは1週間で0.04に低下した。
五、診断ツールと検証フロー
| フェーズ | ツール | データソース | 検証期限 |
|---|---|---|---|
| 問題の特定 | CrUXレポート / GSCの体験レポート | 実ユーザーの28日間データ | 週に1回確認 |
| ラボ環境での再現 | Lighthouse / WebPageTest | Moto G4・低速4Gをシミュレート | 修正前に1回実行 |
| 本番環境の監視 | CrUX / RUMツール | 75パーセンタイル指標の推移 | 公開後14日 |
| 検収 | GSCのCore Web Vitalsレポート | 3種類の指標がすべて「合格」 | 公開後28日 |
よくある失敗はLighthouseのローカルスコアだけを見てしまうことです。Lighthouseが走るのはクリーンな環境で、実際のユーザーのネットワークも、サードパーティスクリプトも、ログイン状態もありません。ローカルでは95点なのにCrUXが不合格というサイトは非常に多くあります。修正後は必ず28日間のローリングデータが更新されるまで待ち、公開3日目で成功と判断しないでください。
パフォーマンス最適化とCore Web Vitals指標の体系自体が継続的な取り組みであり、一度きりのプロジェクトではありません。公式サイト保守期間にはCWV月次レポートを定例項目として入れるべきです。
六、パフォーマンスバジェットを開発フローにどう組み込むか
CWVを一巡修正しても、それで終わりではありません。新機能、新しいプラグイン、新しいマーケティングスクリプトが指標を再び悪化させます。正しいやり方は、パフォーマンスバジェットをリリースフローに組み込み、毎回の公開前にチェックを挟むことです。
| ページの種類 | LCPバジェット | INPバジェット | CLSバジェット | JS総量バジェット |
|---|---|---|---|---|
| トップページとランディングページ | 2.0秒以内 | 150ミリ秒以内 | 0.05以内 | 250KB gzip以内 |
| 製品詳細ページ | 2.5秒以内 | ≤ 200ミリ秒 | 0.1以下 | 350KB gzip以内 |
| ブログ記事ページ | 2.5秒以内 | ≤ 200ミリ秒 | 0.1以下 | 300KB gzip以内 |
| お問い合わせ・フォームページ | 2.0秒以内 | 150ミリ秒以内 | 0.05以内 | 200KB gzip以内 |
毎回のリリース前に、ステージング環境でLighthouse CIを使いこれらの主要ページを計測し、バジェットを超えたらマージを許可しないようにします。マーケティングチームが急遽追加するポップアップ、サポートチャットのスクリプト、ピクセルトラッキングは、レビューチェックリストを通すようにします。このスクリプトは遅延読み込みできるか、ファーストビューの後に回せるか、特定のページだけで読み込めるか。3か月に一度CrUXの月次レポートを作り、75パーセンタイルの推移を見て、ある種のページが2か月連続で悪化していれば改善を起案します。
もう一つ見落とされがちなのが、画像アセットの管理です。新しく書いたブログ記事に未圧縮の原画像をそのままアップロードすると、LCPはすぐに悪化します。コンテンツ管理画面に画像圧縮のパイプラインをデフォルトでつなぎ、アップロード時に自動でWebPへ変換し、適切なサイズまで圧縮し、srcsetを生成するようにすれば、後から1記事ずつ直すよりはるかに楽です。このパイプラインはメディアアセット管理の流れと揃えており、詳しくはメディア資産の管理。
サードパーティスクリプトはINP悪化の最大の原因です。マーケティングチームが新しいキャンペーンのために急遽追加するピクセル、チャットプラグイン、フォーム埋め込みは、遅延読み込みされておらず、すべてファーストビューのレンダリング段階に集中してしまいます。四半期ごとにサイト全体のサードパーティスクリプトの一覧を出して見直します。どれがまだ使われているか、どれをファーストビューの後に遅延できるか、どれがもう誰も見ておらず削除できるか。このレビューをリリースフローの一環として定着させれば、毎回後から最適化するよりずっと楽です。
最後に検証の基準を強調します。修正後はLighthouseのローカルスコアだけを見ず、CrUXの実ユーザー28日間ローリングデータが更新されるのを待ってください。ローカルのスコアは問題の特定にしか使えず、成功を宣言するためには使えません。毎月のCWV月次レポートをエンジニアリングとマーケティングの責任者に定期的に送り、パフォーマンスをチーム横断で見る指標にし、SEO担当者一人のKPIにしないようにしましょう。
FAQ よくある質問
LCP、INP、CLSのうち、どれから直すべきですか？
Lighthouse で 95 点なのに Search Console で不合格になるのはなぜ？
INP を 500 ミリ秒から 200 以内に下げるにはどれくらいかかる？
CLS はどのくらいなら正常？
Core Web Vitals はランキングに直接影響する？
モバイルとデスクトップの CWV は分けて見るべき？
最後に
Core Web Vitals はテクニカル SEO の中で投資対効果が最も明確な項目です。各指標に明確なしきい値、明確な診断ツール、明確な対策があります。Lighthouse のスコアに惑わされず、CrUX の実ユーザーデータを見てください。
実行は 3 ステップ。今週は GSC の体験レポートでどの指標が最も悪いかを特定します。来週は LCP → CLS → INP の順で最初の 1 つを修正します。公開後 28 日で CrUX がすべて合格か確認します。3 指標すべてが合格ラインに入れば、B2B 越境サイトの 70% 以上を上回っています。
覚えておきたい一言：CWV はスコアを競うゲームではなく、実際のユーザーが待たされる時間のこと。LCP は目で、INP は手で、CLS は目で確かめる。三つとも快適でこそ合格だ。