はじめに
本書の目的
本書は、Googleが提唱する「コアウェブバイタル」について、体系的に分かりやすく解説することを目的としています。技術的な背景だけでなく、実務で使える評価基準や改善の考え方も取り上げます。たとえば、ページ表示が遅くて離脱が増える問題や、操作に対する反応が悪くてフォーム送信が失敗するケースなどに役立つ内容です。
想定する読者
主にWeb担当者、SEO担当者、フロントエンドエンジニアを想定しています。初心者でも読み進められるように専門用語は最小限にし、具体例や改善の手順を添えます。
本書の構成
第2章でコアウェブバイタルの位置づけを説明し、第3章以降で主要指標と評価基準、改善方法を順に解説します。各章で実務に即した対策を提示します。
読み方のポイント
まずは全体像を把握し、次に自サイトの計測結果を確認してください。問題点が分かれば、優先順位をつけて段階的に改善していきましょう。
2. コアウェブバイタルとは？概要と位置づけ
定義と目的
コアウェブバイタルは、Googleが定めたWebページの閲覧体験（ユーザーエクスペリエンス）を測る主要な指標群です。主な目的は、読みやすくストレスの少ないページを提供し、ユーザー満足度やビジネス成果を向上させることです。
何を測るか（イメージで説明）
- ページ表示の速さ：主要なコンテンツがどれだけ早く見えるか。たとえば記事の本文がすぐ表示されるか。
- 操作への応答：ボタンを押したときの反応の速さ。フォーム送信やメニュー操作で遅延がないか。
- レイアウトの安定性：読み途中でボタンや画像が動かないか。誤タップを防ぎます。
検索順位との関係
コアウェブバイタルはGoogle検索のランキング要因の一部です。同じ品質のコンテンツ同士では、より良いスコアが順位に有利に働きます。ただし良質なコンテンツが最優先です。
測定方法と見方
代表的なツールはChrome UX Report、PageSpeed Insights、Search Consoleです。スコアは「良好」「改善が必要」「不良」に分類され、具体的な改善点が提示されます。
なぜ重要か
快適な閲覧は直帰率やコンバージョンに直結します。ページを速く安定させることでユーザーの信頼を得やすくなります。
3. コアウェブバイタルを構成する3つの指標
LCP（Largest Contentful Paint）
ページで最も重要なコンテンツ（見出しやメイン画像など）が表示されるまでの時間を測ります。例：トップ記事の大きな画像が表示されるまでの秒数。目安は「良好：2.5秒以内」「要改善：2.5〜4秒」「不良：4秒以上」です。ユーザーは速く主要コンテンツを見たいので、LCPは体感の速さを直接左右します。
INP（Interaction to Next Paint）
ユーザーがクリックや入力をしたとき、その操作に対して画面が描画されるまでの遅延を評価します。旧FIDの代わりに、さまざまな操作を総合して応答性を測る指標です。例：ボタンを押してから反応が表示されるまで。目安は「良好：200ms以下」「要改善：200〜500ms」「不良：500ms以上」です。操作感が良ければ離脱が減ります。
CLS（Cumulative Layout Shift）
ページ読み込み中や操作時に発生するレイアウトのズレ（要素が勝手に動くこと）の総量を測ります。例：画像読み込みで本文が下に押されるといった現象。目安は「良好：0.1以下」「要改善：0.1〜0.25」「不良：0.25以上」です。視覚の安定性が高いと読みやすさと信頼感が増します。
各指標はユーザー体験の別々の側面を評価します。計測は実際の利用状況（フィールドデータ）や開発中のテスト（ラボデータ）で行えます。
3-1. LCP：ページの主なコンテンツが表示される速さ
概要
LCP（Largest Contentful Paint）は、画面上で最も大きなコンテンツが描画されるまでの時間を測ります。ヒーロー画像、大きなテキストブロック、主要な画像や動画のサムネイルが対象です。目安は2.5秒以内で、これを超えると「表示が遅い」と感じやすくなります。
なぜ重要か
ユーザーはページを視覚的に確認して「読み始められるか」を判断します。LCPが速ければ第一印象が良く、離脱を減らせます。
計測のポイント
ラボ（Lighthouse）とフィールド（実際のユーザー）で値が異なることがあります。実測値（フィールド）は回線や端末影響を受けます。まずはフィールドデータを確認してください。
改善の具体例
- 画像最適化：WebPやAVIFに変換、適切な解像度のsrcsetを用意します。LCPとなる画像はpreloadします（例: ）。
- サーバー：CDN導入、キャッシュ設定、TTFB短縮を行います。
- CSS/JS：重要表示に不要なレンダリングブロッキングを減らし、重要なCSSはインライン化、スクリプトはdefer/asyncで読み込みます。
- フォント：主要フォントはpreloadし、font-display:swapを設定します。
チェックツール
PageSpeed Insights、Chrome UX Report、Lighthouse、Search ConsoleのCore Web Vitalsレポートで確認できます。改善はまずLCPの原因を特定することから始めてください。
3-2. INP：ユーザー操作に対する応答の速さ
説明
INP（Interaction to Next Paint）は、ユーザーが画面上で行った操作（クリック、タップ、キー入力など）から画面に次の描画（反応）が出るまでの時間を測る指標です。ページ滞在中の代表的な遅延を評価するため、実際の使い心地に近い数値になります。
FIDとの違い
従来のFIDは「最初の入力遅延」だけを見ていました。これに対しINPは、滞在中に起きた複数の入力の中で代表値を取り、平均的な応答性を示します。つまり最初だけでなく、その後の操作の快適さも評価します。
実際の例
ボタンを押してもページがフリーズして何秒も反応しないと、不快に感じます。これは長時間走るJavaScript処理や重い描画が原因で、INPの値が悪くなります。逆に、操作に対してすぐに視覚的な変化があれば、INPは良好です。
測定と改善のポイント
- メインスレッドの長時間処理を分割する。
- 重いスクリプトは遅延読み込みや非同期実行にする。
- 入力に関わる処理は軽くし、必要なら先に視覚応答を返す（プレースホルダーなど）。
- 実機やフィールドデータでユーザー操作の代表的な遅延を確認する。
これらを意識すると、ユーザーが感じる操作のもたつきを減らせます。
3-3. CLS：レイアウトのズレ（視覚的安定性）
CLSとは何か
CLS（Cumulative Layout Shift）は、ページの読み込み中や操作中に発生する予期せぬレイアウトのずれの大きさと頻度を数値化した指標です。例えば読み進めている最中に文字が飛んだり、画像の読み込みでボタン位置が変わると、ユーザーは誤タップや迷いを感じます。
なぜ重要か（具体例）
- 記事を読んでいたらフォントや画像で本文が下へ移動し、誤って広告をタップした。
- フォーム入力中にボタンが動いて送信先が変わる。
これらは操作を妨げ、信頼感を損ないます。
スコアの考え方（かんたんに）
CLSは “ずれの大きさ” と “発生頻度” を組み合わせて算出します。値が小さいほど視覚的に安定しており、目安は次の通りです：良好は0.1未満、改善が必要は0.1〜0.25、不良は0.25超。
よくある原因
- 画像や広告に幅・高さが指定されていない。
- 遅延読み込みで要素があとから挿入される。
- フォントの切り替えで文字幅が変わる。
- JavaScriptでDOMを上に差し込む。
改善の実践的な対策
- 画像や動画、広告に width/height を指定し、CSSでアスペクト比を固定する。
- プレースホルダー枠を用意して、あとから入る要素の場所を確保する。
- レイアウトを変えるアニメーションは transform や opacity を使う（レイアウト再計算を避けるため）。
- Webフォントは font-display を使うか、重要なテキストにフォールバックを用意する。
- 広告や埋め込みは事前にスペースを予約して遅延挿入する。
測定と確認方法
ChromeのLighthouseやDevToolsのPerformanceパネルでレイアウトシフトを可視化できます。実際のユーザー経験を知るにはフィールドデータ（例：ページビューごとのCLS）も確認してください。
