Core Web Vitals：指標のしきい値と最適化の優先順位
1. 3つの指標は何を測っているのか
Core Web Vitalsは1つのスコアではなく、互いに独立した3つの体験指標の組み合わせです。各指標が何を測っているかを理解して初めて、どこを直すべきかがわかります。
| 指標 | 正式名称 | 測定内容 | 合格ライン | 要改善 |
|---|---|---|---|---|
| LCP | Largest Contentful Paint | ファーストビューの最大要素が描画完了するまでの時間 | 2.5秒以内 | 2.5〜4秒 |
| INP | Interaction to Next Paint | ユーザー操作から次のフレーム描画までの遅延 | ≤ 200ミリ秒 | 200〜500ミリ秒 |
| CLS | Cumulative Layout Shift | 意図しないレイアウトシフトの累積スコア | 0.1以下 | 0.1〜0.25 |
| TTVC | Time to First Contentful Paint 派生 | 最初の有用なコンテンツが描画されるまでの時間 | 1.8秒以内 | 1.8〜3秒 |
重要な認識が2つあります。1つ目は75パーセンタイル。Googleがページの良し悪しを判定するときは、平均値でも最速ユーザーでもなく、75%の実ユーザーがその指標でどうだったかを見ます。2つ目は、INPが2024年3月にFIDを正式に置き換え、それ以降インタラクション遅延が主要指標になったことです。これはオンラインチャット、マーケティングオートメーション、チャットポップアップを多数導入したB2Bサイトに最も影響します。これらのスクリプトこそメインスレッドをブロックする主な原因だからです。
パフォーマンス最適化は単独の作業ではなく、メディア資産の管理と同じことの裏表です。画像を適切に処理しなければLCPは永遠に下がらず、スクリプトを適切に処理しなければINPは永遠に合格しません。サイト内の監視体制の構築方法はサイト監視とアラートのチェックリスト。
2. データソース：3つのツールはそれぞれ何を見るか
多くのチームはパフォーマンス最適化のとき間違ったデータを使い、1週間調整しても指標がまったく改善しないことがあります。ラボ値を見ているからです。
| ツール | データの種類 | サンプリング | 適用シーン | 限界 |
|---|---|---|---|---|
| PageSpeed Insights | ラボ＋フィールドの混合 | 単発の計測＋28日間のCrUX | 単一ページの簡易診断 | ラボ値と実ユーザーには差がある |
| CrUX | フィールドデータ | Chromeユーザーが匿名で報告 | 実際の分布を見る | 小規模サイトはサンプル不足 |
| Search Console | フィールドデータ集計 | 28日間ローリング | テンプレート別に傾向を見る | 単一ページのドリルダウンなし |
| Lighthouse CI | ラボデータ | ローカル計測 | デプロイ前のリグレッション | 実際のオンラインユーザーを代表できない |
| Web Vitals .js | カスタムフィールド計測 | 自社のユーザー | 小規模サイトのサンプル補完 | 開発工数が必要 |
実践の原則：Search Console の Core Web Vitals レポートでどのテンプレートに問題があるかを特定し、PageSpeed Insights で単一ページを掘り下げてボトルネックを探し、Lighthouse CI で毎回のリリース前にリグレッションを確認する。逆をやってはいけない。ラボのスコアをオンラインの実績と見なすのは、パフォーマンス最適化で最もよくある自己欺瞞だ。
三、LCP 最適化：ファーストビューの大画像が最大の敵
B2B サイトの LCP 問題の80%は hero の大画像とファーストビューのカルーセルにある。
| ボトルネック | 典型的な症状 | 最適化の施策 | 期待できる効果 |
|---|---|---|---|
| メイン画像が未圧縮 | hero 画像が500KB以上の PNG | WebP/AVIF に変換、品質80、srcset で複数サイズ | LCP が0.5〜1.5秒短縮 |
| メイン画像が未プリロード | ブラウザが hero 画像を遅く検出 | head に preload を追加してメイン画像を指定 | LCP が0.2〜0.5秒短縮 |
| フォントがレンダリングをブロック | カスタムフォントの読み込みが遅れて白画面 | font-display: swap、必要なウェイトのみ読み込む | LCP が0.3〜0.8秒短縮 |
| サーバー応答が遅い | TTFB が1.8秒超 | CDN 導入、HTTP/2 有効化、PHP キャッシュ | LCP が0.4〜1秒短縮 |
| サードパーティスクリプトが初回描画を遅延 | head 内のトラッキングスクリプトがブロック | defer または idle 後に遅延読み込み | LCP が0.2〜0.6秒短縮 |
見落とされがちな点：B2B サイトでは工場の全景や製品の大画像を hero にすることが多く、この画像は2MB以上の撮影原本であることが多い。200KB以内に圧縮し、WebP を使い、preload を追加する。この3つをやれば LCP は通常半減できる。サーバーが国内にあり顧客が欧米にいる場合、TTFB は必然的に高くなるので CDN は必須だ。
四、INP 最適化：主犯はサードパーティスクリプト
INP が FID に取って代わってから、B2B サイトは軒並み失敗している。こうしたサイトにはマーケティングとカスタマーサポートのスクリプトが多すぎるからだ。
| スクリプトの種類 | よくある提供元 | INP への影響 | 対応方法 |
|---|---|---|---|
| オンラインチャット | Intercom、Zendesk、Tawk | メインスレッドの長いタスクが200〜800ms | ファーストビュー後に3秒遅延して読み込む、または最下部までスクロールしてから読み込む |
| マーケティングオートメーション | HubSpot、Marketo、Pardot | フォームとポップアップが操作をブロック | 対象ページのみで読み込み、対象外ページでは削除 |
| ヒートマップと分析 | Hotjar、FullStory | 記録スクリプトがメインスレッドを継続的に占有 | ユーザーの10%でサンプリング、全量記録はしない |
| チャットポップアップ | WhatsApp、WeCom のフローティングウィンドウ | ポップアップのクリックが遅延 | ネイティブボタンを使い、クリック後にスクリプトを読み込む |
| カスタムカルーセル | トップページの製品カルーセル | 自動再生 JS の長いタスク | CSS カルーセルに変更し、自動再生を停止 |
ボトルネックの判断は Chrome DevTools の Performance パネルでページ操作を一度記録し、Main スレッド上の紫色の長いタスクを見て、最も時間を占めているものから先に処理する。原則：ファーストビューに不要なスクリプトはすべて、ユーザーの初回スクロールまたは idle 5秒後まで遅延させる。プラグインの選択は控えめに。参考：海外サイト向け4プラグインの組み合わせ、入れるほどINPの合格が難しくなります。
5. CLSの最適化：すべてのメディアにサイズを指定
CLSは最も直しやすい指標ですが、最も見落とされがちでもあります。
| ずれの原因 | 原因 | 修正方法 | 修正後のCLS |
|---|---|---|---|
| 画像にサイズ指定なし | imgにwidth/heightがない | 幅と高さの属性かaspect-ratioを追加 | ほぼ0 |
| 広告枠の余白不足 | 広告の非同期読み込みで押し広げられる | コンテナに最小高さを設定 | 0.05〜0.15低下 |
| フォントの切り替え | FOIT/FOUTによる再レイアウト | font-display: swap、フォールバックフォントのサイズを確保 | 0.02〜0.08低下 |
| コンテンツの動的挿入 | おすすめ枠や関連記事を後から挿入 | プレースホルダーコンテナの高さを確保 | 0.05〜0.1低下 |
| 遅延読み込み画像の到着遅れ | loading=lazyの画像が遅れて下の要素を押し下げる | プレースホルダー画像かaspect-ratio | 0.03〜0.07低下 |
絶対ルールが一つあります。ページ上のすべてのimg、video、iframeには、HTMLでwidthとheightの属性を必ず書き、CSSのaspect-ratioでレスポンシブを保つこと。これに開発のスケジュール調整は不要で、テンプレートを一度直せばサイト全体が恩恵を受けます。アクセシビリティとパフォーマンスはサイズ確保の面で同じ作業です。詳しくはB2Bサイトのアクセシビリティ対応範囲。
6. 最適化の優先順位と改善サイクル
| フェーズ | サイクル | 目標 | アクション | 達成指標 |
|---|---|---|---|---|
| 1週目 | 診断 | 問題のあるテンプレートを特定 | Search Consoleで28日分のデータを取得し、ワースト10ページを洗い出す | 問題テンプレートのリスト |
| 2週目 | LCPの集中対策 | すべてのテンプレートでLCPを2.5秒以内に | 画像圧縮 + preload + フォント最適化 | PSIのLCP分布 |
| 3週目 | INPの集中対策 | サードパーティスクリプトの削減 | 遅延読み込み、サンプリング記録、不要スクリプトの削除 | ロングタスク数を50%削減 |
| 4週目 | CLSの仕上げ | サイト全体のCLSを0.1未満に | 幅と高さの属性、プレースホルダーコンテナ | GSCでCLSエラーのページなし |
| 継続 | 監視 | リリースで後退させない | デプロイごとにLighthouse CIを実行 | スコアが前バージョンを下回らない |
サイト運用には決まったリズムがあり、パフォーマンスはその一部です。詳しくは月次6つのメンテナンスタスクをご覧ください。リニューアルや移行の後はパフォーマンスが後退しやすいので、移行時の301リダイレクトとSEO保全と合わせて確認してください。
FAQ よくある質問
最後に
Core Web Vitals は技術チームだけの課題ではなく、コンテンツ、デザイン、マーケティングの 3 者が共同で担う指標です。画像サイズはコンテンツ、スクリプト読み込みはマーケティング、レイアウトシフトはデザインの責任です。この 3 者を同じテーブルに集め、LCP、INP、CLS の順にそれぞれ 2 週間ずつ修正すれば、1 四半期以内にサイト全体を合格させることは実現可能です。
導入は3ステップ。今週は Search Console からワースト10のテンプレートをリストアップ。来週は hero 画像を圧縮して preload を追加。再来週はカスタマーサポートとマーケティングのスクリプトをすべて遅延読み込みに。ここまで終えてから GSC を確認すると、不合格率はたいてい半分以下になります。
覚えておきたい一言。パフォーマンス改善のコストは実際のユーザーに使うべきです。現場のデータを見て、ファーストビューの大きな画像を直し、サードパーティスクリプトを後ろに回す。これはスコアで満点を取るより十倍重要です。