Core Web Vitals改善の提案、事業インパクトはどこまで信じていいか

2026年10月8日にGoogle web.devのWeb Vitals本文を再確認した。現在のCore Web VitalsはLCP（読み込み）、INP（操作への応答）、CLS（視覚の安定性）で、推奨値はモバイル/デスクトップ別の75パーセンタイルで評価する。CrUXやSearch Consoleなどのフィールドデータと、Lighthouse等のラボ測定は目的が異なり、指標の改善をそのまま売上・順位・満足度へ換算しない。事業判断では対象ユーザー、収益導線、期間、実験とRUMのデータを結び付ける。

「表示速度を改善すれば、売上が増える」という提案を受けたとき、まず確認したいのは、自社のどの利用場面を、どの指標で、どこまで改善する計画なのかです。技術指標が良くなることと、追加費用を上回る利益が得られることは、分けて確かめる必要があります。

この記事は改善手法の一覧ではなく、投資を判断する責任者向けです。現在の状態、事業の成果に至る経路、利用者の環境という3条件から、必要な測定と採算の仮定を整理します。

30秒で要点

• Core Web Vitals（CWV）はLCP・INP・CLS。利用者の読み込み、操作への反応、表示の安定性に関する指標で、売上の予測式ではない。
• 良好の目安は75パーセンタイルでLCP 2.5秒以下、INP 200ミリ秒以下、CLS 0.1以下。端末区分と測定条件を揃える。
• 実利用のフィールドデータと、条件を設定したラボ測定を区別する。Lighthouseのスコアだけで事業効果を見積もらない。
• 「1秒で7%」のような一律の倍率を採用せず、影響対象、成立注文、利益、運用費の仮定を置き、効果ゼロの場合も比較する。

指標の境界と、投資の境界は違う

Googleが示すCWVの区分は次の通りです。「要改善」は良好と不良の間です。LCPとINPは時間、CLSは単位のない値であり、3つを足して平均するものではありません。

表が収まらない場合は、横にスクロールできます

例えばINPが500ミリ秒ちょうどなら、不良ではなく要改善の範囲です。CWVの評価では、モバイルとデスクトップを分け、75パーセンタイルを使います。これは、対象の観測値の75%がその値以下に収まる位置です。平均値が速くても、遅い利用者の体験が残ることがあります。CWVの定義と閾値の公式説明で条件を確認できます。

不良の指標があることは調査の理由になりますが、「直せば購入が何%増える」という意味ではありません。良好でも、重要な操作の失敗や特定端末での不便は残り得ます。反対に数値が悪くても、原因、影響する人数、修正費用を調べる前に、大規模な作り直しが必要とは決められません。

提案書の数字を、測定条件へ戻す

「1秒の改善でコンバージョン率が7%上がる」という数値を、自社の保証や既定の予測としては使いません。元の調査、対象業種、実施条件、成果の分母が分からないままでは、再現性を判断できないためです。本記事ではこの7%を裏付ける一次研究を採用しておらず、実証された効果として紹介していません。

提案者には、対象ページと操作、測定日、端末・回線、実利用かラボか、改善前後の比較方法を示してもらいます。「スコアが20点上がる」だけでなく、利用者が何をできるようになるのかを説明してもらうと、業務上の優先順位を比較しやすくなります。

検索順位についても別の論点です。GoogleはCWVをランキングシステムで使用すると説明しつつ、良好なスコアが上位表示を保証しないとしています。順位への具体的な重みや売上増加率は、ここで採用した説明には示されていません。Googleのページエクスペリエンス解説を根拠の範囲として扱います。

現状・事業経路・利用環境の3条件を見る

現在どこで不便が起きているか

ページ全体の点数だけでなく、商品画像が見えるまで、選択肢を開いた後、送信ボタンを押した後など、重要な場面と指標を結びます。画像表示はLCP、操作の反応はINP、途中で押す位置が動く問題はCLSが調査の入口になることがあります。

ただし、指標だけでは全原因は分かりません。送信自体の失敗、内容の分かりにくさ、利用支援技術での操作の問題などは、別の機能・使いやすさの確認も必要です。良好の境界に入れることを唯一の完了条件にしません。

改善がどの成果経路に届くか

購入完了を測るECでも、検討が長い商品と、その場で買う消耗品では追跡すべき期間が違います。BtoBの相談でも、初回訪問、資料閲覧、再訪、商談、契約を分けて考えます。業種名だけで効果が大きい・小さいとは決めません。

例えば商品一覧だけを改善する提案なら、その一覧を使う利用者が投資効果の主な対象です。サイト全体の売上に同じ改善率を掛けると、対象外の経路まで便益に含めることになります。

誰の環境を代表する測定か

回線、端末の処理能力、キャッシュ、ページの状態によって結果は変わります。高性能な社内PCで一度速かったことと、実利用者の分布が改善したことは同じではありません。モバイル比率だけでなく、対象ページや入口の構成が前後で変わっていないかも確認します。

これらの条件は、効果を保証する3要件ではありません。どの仮定が採算を左右するかを見つけるための材料です。

フィールドとラボを、別の用途で使う

表が収まらない場合は、横にスクロールできます

PageSpeed Insights等を見るときは、実利用データの欄とラボ診断の欄を混同しません。データがない場合は「良好」ではなく、その集計では判断できない状態です。CrUXのような公開フィールドデータと、自社で収集する利用データも、対象範囲を確かめて使います。

通常のLighthouseのページ読み込み測定では、利用者の操作がないためINPそのものを測れず、TBT（メインスレッドが長く塞がれる時間の指標）を改善の手がかりとして使います。TBTの改善を、そのままINPの実測改善と表記しないことが必要です。web.devの測定方法の説明に沿って、ラボで候補を絞り、フィールドで追う条件を決めます。

架空の採算表で、必要な効果を逆算する

次は測定結果ではなく、判断のための仮定です。改善対象の月間セッションは10,000、現在の成立注文率は2.0%とします。1件あたりの貢献は売上から商品原価・決済・配送など増分の変動費を引いた3,000円。初期改善費は300,000円、追加運用費は毎月5,000円です。

表が収まらない場合は、横にスクロールできます

0.1ポイントは2.0%から2.1%への変化です。追加注文は10,000×0.001＝10件、月正味は10×3,000−5,000＝25,000円、単純回収は300,000÷25,000＝12か月です。「0.1%増」という相対変化とは区別します。

単純回収期間は、効果が直ちに一定で続くと仮定した計算です。遅れて効果が出る場合、需要の変化、追加修正、税、資金の時間価値はこの表に含めていません。見積もりではそれらを必要に応じて加えます。修正工数を初期費用に含めたなら、同じ工数を月運用費にも重複計上しません。

この式は「どの仮定なら支払えるか」を示すものです。0.1ポイントの改善が実際に起きる根拠にはなりません。効果の幅が分からない段階では、小さな測定や修正へ分割する案、受付不具合など別の投資案も比較します。

大きな契約の前に確認する最小単位

1. 対象ページ群と利用場面を1つ選び、指標の現状、データ期間、端末区分、対象人数や件数を残す。
2. 成立注文や有効相談の定義と追跡期間を決める。計測設定と、営業・受注記録への接続を確認する。
3. 原因候補に対応する小さな修正を選び、ラボの条件と機能確認の項目を揃える。元に戻す方法も用意する。
4. 修正後のフィールド指標と成果を追う。価格、在庫、広告、流入構成、季節など同時に変わった条件を記録する。
5. 比較可能な群や期間があるかを確認し、採算表の仮定を更新する。データ不足なら「効果未確定」とする。

過去のサーバー移行の前後も調査の手がかりになりますが、同時にデザインや広告が変わっていれば速度だけの効果を取り出せません。実験が可能な場合も、対象の割当、必要な標本、観測期間を検討してから始めます。この記事では実サイト測定や実ブラウザ操作を行った結果を掲載していません。

実装を決めた後に渡す情報

制作・開発担当へは、目標スコアだけでなく、対象経路、守る機能、利用環境、費用上限、評価期間を渡します。良好の閾値を目指す理由と、事業上の採否条件を別欄にすると、技術改善だけを売上達成と扱う混乱を減らせます。

実装の全体像はWebパフォーマンス完全ガイド、測定と改善の入口はWebパフォーマンス最適化入門で確認できます。具体策はJavaScript・CSS最適化と画像最適化へ進んでください。