GoogleはCore Web Vitalsと呼ばれる3つの指標を測定しております。LCP、FID、CLSでございます。
これらは技術的に聞こえます。実際に技術的でございます。
しかし、これらは収益に直接影響を及ぼします。
本稿では、これらがビジネス用語で何を意味するのか、収益にどのように影響するのか、そしてどれから優先して修正すべきかをご説明いたします。
Core Web Vitalsとは何か（平易な解説）
Googleはウェブサイトがユーザーにとってどれほど高速で安定して感じられるかを測定しております。
3つの指標は以下の通りでございます。
LCP - Largest Contentful Paint
技術的定義： 最も大きな可視要素が読み込まれるまでの時間。
平易な説明： メインコンテンツが表示されるまでの時間。
ユーザー体験： 「空白の画面をどれだけ眺めることになるのか」
良好： 2.5秒未満
不良： 4秒超
ビジネスへの影響：
- 1秒の遅延ごとに、コンバージョンが7%減少
- LCPが遅い場合、ユーザーはコンテンツを見る前に離脱
FID - First Input Delay（2024年にINPに置き換え）
技術的定義： ユーザーの操作からブラウザが応答するまでの時間。
平易な説明： クリックしてから何かが起こるまでの時間。
ユーザー体験： 「クリックは効いたのか。もう一度クリックすべきか」
良好： 100ミリ秒未満
不良： 300ミリ秒超
ビジネスへの影響：
- FIDが遅いと、ユーザーは複数回クリックし、苛立ち、離脱する
- フォームが壊れているように感じられる
- ボタンが反応しないように感じられる
CLS - Cumulative Layout Shift
技術的定義： 可視コンテンツが予期せず移動する量。
平易な説明： 読み込み中にコンテンツが飛び跳ねるか。
ユーザー体験： 「あのボタンを押そうとしたのに、広告が読み込まれて間違ったものをクリックしてしまった」
良好： 0.1未満
不良： 0.25超
ビジネスへの影響：
- ユーザーが誤ったボタンをクリックしてしまう
- フォーム入力がストレスになる
- プロフェッショナルでなく、壊れているように感じられる
実際の収益への影響（ランキングだけではない）
Core Web Vitalsはビジネスに2つの方法で影響を及ぼします。
影響1：Googleランキング
重要度：
- 小さなランキング要素である
- コンテンツの質や被リンクほど重要ではない
- しかし他の条件が同じであれば、高速なサイトが勝つ
現実の確認： 優れたコンテンツを持つ遅いサイトは、弱いコンテンツを持つ高速なサイトに勝ります。
完璧なスコアを追い求めてコンテンツの質を犠牲にしてはなりません。
影響2：コンバージョン率（はるかに大きな影響）
実データ：
Amazon：
- 100ミリ秒の遅延ごとに、収益が1%減少
Google：
- 0.5秒の遅延で、トラフィックが20%減少
Walmart：
- 1秒の改善ごとに、コンバージョンが2%増加
御社のビジネスの場合：
- LCPが4秒超の場合、直帰率は50%
- LCPが2.5秒未満の場合、直帰率は20%
- 差分：60%多くの人がサイトに留まる
収益計算例：
例：Eコマースサイト
- 月間10,000訪問
- 現在のLCP：4.5秒（直帰率50%）
- 5,000人が商品を閲覧
- 2%がコンバージョン = 100件の販売
- 平均注文額$100 = 収益$10,000
LCPを2.3秒に改善した後：
- 月間10,000訪問
- 新しいLCP：2.3秒（直帰率20%）
- 8,000人が商品を閲覧（60%増）
- 2%がコンバージョン = 160件の販売
- 平均注文額$100 = 収益$16,000
- 月$6,000の増加 = 年$72,000
LCP修正コスト： $0〜500（無料の場合が多く、より良いホスティングが必要な場合もある）
ROI： $500を支払って修正した場合、14,400%
どの指標が御社にとって最も重要か
すべてのCore Web Vitalsが等しく重要というわけではございません。
Eコマース：LCPが最重要
理由： 商品画像が通常LCP要素となります。
問題点： 最適化されていない大きな商品画像 = 遅いLCP = ユーザーが商品を見る前に離脱。
優先順位：
- LCP（最重要）
- CLS（2番目 - チェックアウト時のレイアウトシフトをユーザーは嫌う）
- FID（3番目 - ボタンは通常きちんと反応する）
すぐに実行できる改善策： 画像を最適化してください。WebPフォーマットを使用してください。スクロール下部の画像は遅延読み込みを行ってください。
SaaS / Webアプリ：FID/INPが最重要
理由： ユーザーは頻繁に操作いたします（ボタンクリック、フォーム入力、インターフェース利用）。
問題点： 遅いJavaScript = クリックが壊れているように感じる = 苛立ったユーザーがサインアップをキャンセル。
優先順位：
- FID/INP（最重要）
- LCP（2番目 - 遅いダッシュボード読み込みは煩わしい）
- CLS（3番目 - アプリではレイアウトシフトが少ない）
すぐに実行できる改善策： 未使用のJavaScriptを削除してください。重要でないスクリプトを遅延させてください。
ブログ / コンテンツサイト：LCPとCLSが重要
理由： ユーザーは読みに来ております。コンテンツが速く読み込まれ、動かないことが必要です。
問題点： 広告と画像がレイアウトシフトを引き起こします。大きなヒーロー画像はLCPを遅くします。
優先順位：
- LCP（最重要 - ユーザーは読みたい）
- CLS（2番目 - 広告がコンテンツをずらすと激しい不満を招く）
- FID（3番目 - ブログ記事では操作が少ない）
すぐに実行できる改善策： 広告のためのスペースを予約してシフトを防いでください。ヒーロー画像を最適化してください。
リードジェネレーション / サービスサイト：フォームのためにLCPとCLS
理由： 目標はフォーム送信でございます。ユーザーはストレスなくフォームを記入する必要がございます。
問題点： 画像がLCPを遅くします。レイアウトシフトはフォームを煩わしくいたします。
優先順位：
- CLS（最重要 - フォームのシフトはユーザーの離脱を招く）
- LCP（2番目 - 高速なランディングページ = フォーム閲覧数増）
- FID（3番目 - 重いJSがない限り、フォームは通常きちんと反応する）
すぐに実行できる改善策： すべての画像に明示的な幅と高さを設定してください。フォーム近くのレイアウトをシフトさせる要素を削除してください。
指標別のすぐに実行できる改善策
LCPのすぐに実行できる改善策
問題： 大きな画像の読み込みが遅い。
修正案（影響度順）：
-
画像を最適化（5〜10分）
- WebPフォーマットに変換
- TinyPNGやSquooshで圧縮
- 影響：LCPが30〜50%改善
-
画像にCDNを使用（30分）
- Cloudflare、Cloudinary、ImgIX
- ユーザーに最も近いサーバーから画像を配信
- 影響：LCPが20〜40%改善
-
LCP画像をプリロード（10分）
<head>に追加：<link rel="preload" as="image" href="hero.jpg">- ブラウザが即座に読み込む
- 影響：LCPが10〜30%改善
-
レンダリングをブロックするリソースを削除（30〜60分）
- 重要でないCSSを遅延
- JavaScriptを末尾に移動するか遅延
- 影響：LCPが20〜50%改善
期待される改善： LCPが1〜2秒短縮
所要時間： 1〜2時間
コスト： $0（無料ツール）
FID/INPのすぐに実行できる改善策
問題： JavaScriptがメインスレッドをブロック。
修正案（影響度順）：
-
未使用のJavaScriptを削除（30分）
- Chrome DevToolsのCoverageタブで確認
- 使用していないプラグインを削除
- 影響：FIDが30〜60%改善
-
重要でないJavaScriptを遅延（15分）
defer属性を追加：<script defer src="script.js">- ページがインタラクティブになった後にスクリプトを読み込む
- 影響：FIDが40〜70%改善
-
コードスプリッティングを使用（60分、技術的）
- 現在のページに必要なJavaScriptのみを読み込み
- ビルドツールの変更が必要
- 影響：FIDが50〜80%改善
-
ホスティングをアップグレード（遅い共有ホスティングの場合）
- より高速なサーバーに移動
- より多くのCPU = 高速なJS実行
- 影響：FIDが20〜50%改善
期待される改善： FIDが100〜200ミリ秒短縮
所要時間： 1〜3時間
コスト： $0〜50/月（ホスティングをアップグレードする場合）
CLSのすぐに実行できる改善策
問題： 要素が読み込まれるとコンテンツが下方にシフトする。
修正案（影響度順）：
-
画像に明示的な寸法を設定（30分）
- 幅と高さを追加：
<img src="photo.jpg" width="800" height="600"> - 画像読み込み前にブラウザがスペースを予約
- 影響：CLSが50〜80%改善
- 幅と高さを追加：
-
広告のためのスペースを予約（15分）
- 広告コンテナにmin-heightを追加
- 広告読み込み時のシフトを防ぐ
- 影響：CLSが30〜60%改善
-
font-display: swapを使用（5分）
@font-faceに追加：font-display: swap;- 空白テキストの代わりにフォールバックフォントを即座に表示
- 影響：CLSが20〜40%改善
-
既存コンテンツの上にコンテンツを挿入することを避ける（場合による）
- コンテンツを下に押し下げるバナーを追加しない
- 予約済みスペースに動的コンテンツを読み込む
- 影響：適切に行えばCLSを完全に排除
期待される改善： CLSが0.25から0.1未満へ
所要時間： 1〜2時間
コスト： $0
優先すべき場合と無視すべき場合
Core Web Vitalsを優先すべき場合：
高トラフィック、低コンバージョン：
- 月間10,000以上の訪問があるが、コンバージョンが2%未満
- 速度を改善することで大きな収益を解放できる可能性
Eコマース：
- 一瞬一瞬の積み重ねが売上に直結
- ROIの計算が容易
モバイル中心のトラフィック：
- モバイルユーザーは遅いサイトに対してより敏感
- モバイルのCore Web Vitalsはデスクトップより悪いことが多い
競争の激しいニッチ：
- 競合他社のスコアがより良い
- 他の条件が同じであれば、高速なサイトに負ける
有料トラフィック：
- 遅いサイトのために離脱するクリックに費用を支払っている
- 広告費の無駄遣い
Core Web Vitalsを優先順位を下げてよい場合：
低トラフィック：
- 月間1,000訪問未満
- 他の事項（コンテンツ、SEO、マーケティング）を修正するほうが大きな影響をもたらす
既に高コンバージョン：
- コンバージョン率5%以上
- 速度は制限要因ではない
コンテンツ品質の問題：
- 薄いコンテンツ、価値提案の欠如、不明確なオファー
- 速度を最適化する前にこれらを修正すべき
忍耐強いユーザーを持つB2B：
- エンタープライズ顧客は複雑なダッシュボードを待つ
- 1〜2秒の遅延に対してそれほど敏感ではない
ニュース / 緊急性のあるコンテンツ：
- 速報ニュースサイト
- コンテンツが十分に価値があれば、ユーザーは待つ
Core Web Vitalsを確認する方法
方法1：PageSpeed Insights（無料、迅速）
- PageSpeed Insightsにアクセス
- URLを入力
- 30〜60秒待つ
- モバイルとデスクトップのスコアを確認
メリット：
- 無料
- 高速
- Google公式ツール
デメリット：
- 一度に1ページしかテストできない
- ラボデータ（シミュレーション）であり、実際のユーザーデータではない
方法2：Google Search Console（無料、実際のユーザー）
- Search Console > エクスペリエンス > Core Web Vitalsへ
- 実際の訪問者からの実ユーザーデータを確認
- 不良、改善が必要、良好のスコアを持つページが表示される
メリット：
- 実際のユーザーデータ（フィールドデータ）
- すべてのページが表示される
- 無料
デメリット：
- データのために十分なトラフィックが必要
- 週次更新であり、リアルタイムではない
方法3：Site Audit（高速、実行可能）
- Site Auditを実行（$50）
- Core Web Vitalsスコアと優先順位付き修正リストを取得
- 問題を引き起こしている正確な要素を確認
- 実装ガイドを取得
メリット：
- 優先順位付きの具体的な修正
- 技術的および非技術的な説明
- 1ページだけでなくサイト全体の監査
デメリット：
- $50のコスト（しかし診断時間を節約）
Site Auditを実行してCore Web Vitalsを確認
よくある間違い
間違い1：100/100スコアを追い求める
問題： 完璧なPageSpeedスコアに執着する。
現実：
- 90以上は素晴らしい
- 80〜89はほとんどのビジネスにとって十分
- 90から100に上げてもビジネスへの影響はわずか
より良いアプローチ： 80〜90に到達したら、コンテンツとマーケティングに集中してください。
間違い2：モバイルを無視する
問題： デスクトップスコアのみを確認する。
現実：
- トラフィックの60〜70%がモバイル
- モバイルスコアは通常より悪い
- Googleはモバイルパフォーマンスに基づいてランク付けする
修正： 常にモバイルスコアを最初に確認してください。
間違い3：誤ったページを最適化する
問題： 商品ページが遅いのにホームページを修正している。
現実： 収益を生み出すページを最適化してください：
- 商品ページ（Eコマース）
- ランディングページ（リードジェネレーション）
- 価格ページ（SaaS）
- 最もトラフィックの多いブログ記事
修正： ホームページだけでなく、収益を生み出す上位5ページでSite Auditを実行してください。
間違い4：速度のために機能を壊す
問題： スコア改善のために重要な機能を削除する。
現実：
- チャットウィジェットは500ミリ秒追加するが、コンバージョンの20%を生み出す
- スコア向上のためにそれを削除する = 収益の損失
修正： 重要な機能の周りで最適化してください。それらを削除しないでください。
期待されるタイムライン
第1週：すぐに実行できる改善策
- 画像を最適化（WebP、圧縮）
- 画像に幅/高さを追加
- 重要でないJavaScriptを遅延
期待される改善：
- LCP：1〜2秒高速化
- CLS：50〜70%改善
第2〜3週：より深い修正
- CDNの設定
- 未使用のJavaScriptを削除
- レンダリングをブロックするリソースを修正
期待される改善：
- LCP：30〜40%の追加改善
- FID：50〜70%改善
第2か月：監視と反復
- Search Consoleで実際のユーザーデータを監視
- コンバージョン率の変化を追跡
- 影響に基づいて微調整
期待される改善：
- コンバージョン率：10〜30%増加
- 収益：測定可能な向上
結論
Core Web VitalsはGoogleが測定する3つの速度指標でございます：
- LCP：メインコンテンツがどれだけ速く読み込まれるか
- FID/INP：サイトがクリックにどれだけ速く反応するか
- CLS：コンテンツがどれだけ動き回るか
ビジネスへの影響：
- 小さなランキング要素
- 大きなコンバージョン要素（1秒ごとに7%のコンバージョン損失）
ビジネスタイプ別の優先順位：
- Eコマース：LCPを最初に
- SaaS：FID/INPを最初に
- ブログ：LCPとCLS
- リードジェネレーション：CLSを最初に
すぐに実行できる改善策：
- 画像を最適化（1〜2時間、無料）
- JavaScriptを遅延（30分、無料）
- 画像の寸法を設定（30分、無料）
期待されるROI： $500の修正で、典型的なEコマースサイトの場合、年間$72,000の追加収益を生み出すことが可能でございます。
100/100のスコアを追い求めないでください。80〜90に到達したら、コンテンツとマーケティングに集中してください。
関連記事：