コアウェブバイタル（CWV）とは何か
コアウェブバイタル（Core Web Vitals）は、Googleがページのユーザー体験を評価するために定めた3つの指標です。具体的にはLCP（Largest Contentful Paint）、CLS（Cumulative Layout Shift）、INP（Interaction to Next Paint）の3つで構成されます。
これらはランキング要因の一部であると同時に、実際のユーザー離脱率にも直結するため、SEOとUXの両面から改善する意義があります。ただし「全部一度に直そう」とすると手が回らなくなるのが現実です。本記事では、どの指標から優先的に取り組むべきかの判断基準と、実務で効果が出やすい施策を整理します。
PageSpeed Insightsの読み方：まず見るべきポイント
改善の第一歩は現状把握です。PageSpeed Insights（PSI）でURLを入力すると、フィールドデータ（実ユーザーデータ）とラボデータ（シミュレーション）の2種類の結果が表示されます。
フィールドデータを最優先で確認する
PSIの画面上部に表示される「実際のユーザーの環境で評価する」セクションがフィールドデータです。これはChrome UX Report（CrUX）から取得された実際のユーザー体験データであり、Googleの検索ランキング評価に使われるのはこちらの値です。
ラボデータはあくまで開発環境でのシミュレーション結果なので、フィールドデータと乖離することがあります。改善の優先順位はフィールドデータの値をもとに判断しましょう。
「不良」と「改善が必要」の違い
各指標は「良好」「改善が必要」「不良」の3段階で評価されます。「不良」に該当する指標があれば最優先で対処が必要です。「改善が必要」の段階であれば、影響度の大きいものから順に取り組むのが効率的です。
LCP・CLS・INP、どこから手をつけるか
3指標すべてが「不良」であるケースは少なく、多くのサイトでは1〜2指標に課題が集中します。優先順位の考え方を整理します。
LCP（Largest Contentful Paint）
ページの主要コンテンツが表示されるまでの時間を測定する指標です。基準値は2.5秒以内が「良好」。ファーストビューの体感速度に直結するため、ユーザーの直帰率への影響が大きい指標です。
LCPが不良の場合は最優先で改善すべきケースが多いです。原因の大半は画像の最適化不足、サーバーレスポンスの遅延、レンダリングブロックリソースの3つに絞られます。
CLS（Cumulative Layout Shift）
ページ読み込み中にレイアウトがどれだけ動いたかを数値化した指標です。基準値は0.1以下が「良好」。広告やWebフォント、サイズ未指定の画像が主な原因です。
CLSは修正がピンポイントで済むことが多く、費用対効果が高い傾向にあります。LCPが良好でCLSが不良なら、先にCLSを片付けるのも有効です。
INP（Interaction to Next Paint）
ユーザーの操作（クリック・タップ・キー入力）から画面が更新されるまでの応答性を測る指標です。基準値は200ミリ秒以内が「良好」。主にJavaScriptの処理負荷が原因になります。
INPは改善の難易度が高く、アプリケーション全体のJS設計に踏み込む必要が出る場合があります。LCP・CLSが良好な状態で残る課題がINPであれば、段階的に取り組みましょう。
実務で効果が出やすい改善施策
各指標ごとに、着手しやすく効果の大きい施策をまとめます。
LCPの改善施策
- 画像の最適化：LCP要素がヒーロー画像である場合、WebP/AVIF形式への変換と適切なサイズ指定が効果的です。
<img>タグにwidth/height属性を明示し、fetchpriority=”high”を付与することでブラウザに優先読み込みを指示できます。 - サーバーレスポンスの改善：TTFB（Time to First Byte）が遅い場合、CDNの導入やサーバーサイドキャッシュの見直しが有効です。WordPressサイトならページキャッシュプラグインの導入だけで大幅に改善することがあります。
- レンダリングブロックの排除：使っていないCSSの除去、JavaScriptのdefer/async読み込みを徹底します。
CLSの改善施策
- 画像・動画のサイズ指定：すべてのメディア要素にwidth/heightを明示し、CSSでaspect-ratioを設定します。
- Webフォントの安定化：font-display: swapの適用と、可能であればフォントのプリロード（
<link rel="preload">）を行います。 - 広告・埋め込みの領域確保：広告枠には最小高さ（min-height）をCSSで事前に確保し、読み込み完了前後でレイアウトが動かないようにします。
INPの改善施策
- 長時間タスクの分割：50ミリ秒を超えるJavaScriptタスクをyield（requestIdleCallbackやscheduler.yield）で分割し、メインスレッドのブロックを減らします。
- 不要なJSの削減：Chrome DevToolsのCoverageパネルで未使用コードを特定し、コード分割やtree shakingで削減します。
- イベントハンドラの最適化：スクロールやリサイズイベントにはdebounce/throttleを適用し、処理量を制御します。
改善サイクルの回し方
CWV改善は一度の対応で完結するものではありません。Googleのフィールドデータは過去28日間のローリング集計で更新されるため、施策を実施してから効果がフィールドデータに反映されるまでには数週間かかります。
改善サイクルとしては、以下の流れが実務的です。
- PSIまたはSearch Consoleの「ウェブに関する主な指標」レポートで現状を把握
- 「不良」判定の指標から優先的に施策を実施
- ラボデータで即時の効果確認（施策が正しく効いているか）
- 2〜4週間後にフィールドデータで実ユーザーへの効果を確認
定期的なスコア確認を習慣化するなら、MINAMIのページ診断レポートを使ってCWVスコアを定点観測するのが効率的です。対象URLを登録しておけば、指標の推移を時系列で追えるため、施策前後の変化を見落としにくくなります。
よくある落とし穴
CWV改善で陥りがちなミスをいくつか挙げます。
- ラボデータだけで判断する：ラボのスコアは改善されたのにフィールドデータが変わらないケースがあります。実ユーザーのデバイス分布や通信環境を考慮してフィールドデータを基準にしましょう。
- モバイルを見ていない：Googleの評価はモバイル基準です。デスクトップだけスコアが良くても、モバイルが不良なら改善されたとは言えません。
- トップページだけ改善する：CWVはURL単位（またはURLグループ単位）で評価されます。流入の多いページを中心に幅広く対応する必要があります。
どのページから改善すべきか迷う場合は、Search Consoleで流入数の多いURLとCWVの「不良」URLを突き合わせるか、MINAMIでサイト全体のパフォーマンス傾向を把握したうえで優先度を決めると、限られたリソースで最大限の効果を出しやすくなります。
まとめ
コアウェブバイタルの改善は「全部を一度に」ではなく、フィールドデータに基づいて優先度を判断し、効果の出やすい施策から着手するのが鉄則です。LCPはユーザー体感速度への影響が大きいため最優先になりやすく、CLSは修正のコスパが良い傾向にあり、INPはJS設計に踏み込むため計画的に取り組む必要があります。施策→計測→改善のサイクルを地道に回すことが、結果としてSEO評価とユーザー体験の両方を底上げする近道です。