1. Core Web Vitalsとは
Core Web Vitals(コアウェブバイタル)は、Googleが定義するWebページのユーザーエクスペリエンス品質を測定するための3つの重要指標です。2021年よりGoogleの検索ランキング要因として正式に組み込まれ、SEO成功において欠かせない要素となっています。
Core Web Vitalsの3つの指標
これらの指標は読み込み速度、操作性、視覚的安定性という3つの側面からWebページの品質を客観的に評価します。
LCP
Largest Contentful Paint ページの読み込み速度
FID
First Input Delay インタラクティブ性
CLS
Cumulative Layout Shift 視覚的安定性
SEOへの影響
検索順位への影響
Core Web VitalsはGoogleのPage Experience Updateの中核を構成しており、特にモバイル検索結果においてランキングシグナルとして直接評価されます。
- Page Experience Updateの一環として評価
- モバイル検索での重要度が特に高い
- 同等品質のコンテンツ間では決定的要因
- 悪い数値は順位下降の原因となる
ユーザー体験への影響
ページの表示速度や操作性が改善されると、ユーザーはストレスなくコンテンツを閲覧でき、サイト全体のエンゲージメント指標が大幅に向上します。
Googleの調査によれば、ページの読み込み時間が1秒から3秒に増加すると直帰率は32%上昇し、5秒になると90%まで跳ね上がります。Core Web Vitalsの改善はユーザー離脱を防ぎ、滞在時間やページ回遊率を高めるだけでなく、最終的なコンバージョン率向上にも直結するため、ビジネス成果の観点からも非常に重要です。
- 直帰率の改善
- コンバージョン率の向上
- ユーザー満足度の向上
- リピート訪問率の向上
目標値一覧
Googleが推奨するCore Web Vitalsの評価基準は以下のとおりで、ユーザーの75パーセンタイル値で判定されます。
各指標には「良好」「改善が必要」「不良」の3段階が設定されており、Search Consoleでもこの基準に基づいてURLがグループ化されます。目標は全ページで「良好」判定を達成することですが、まずはField Dataの75パーセンタイルで「改善が必要」以上を目指し、段階的にすべてのURLを「良好」圏内へ改善していくアプローチが現実的です。
| 指標 | 良好 | 改善が必要 | 不良 |
|---|---|---|---|
| LCP | ≤ 2.5秒 | 2.5 - 4.0秒 | > 4.0秒 |
| FID | ≤ 100ms | 100 - 300ms | > 300ms |
| CLS | ≤ 0.1 | 0.1 - 0.25 | > 0.25 |
2. LCP(Largest Contentful Paint)
LCPは、ページの読み込み開始から最大のコンテンツ要素が表示されるまでの時間を測定します。ユーザーがページの主要コンテンツをいつ見ることができるかを示す重要な指標です。
LCPの対象要素
LCPの測定では、ビューポート内に描画されるすべてのコンテンツ要素の中から最も面積の大きいものが自動的に選択されます。ページによってLCP要素は異なり、ブログ記事ではHero画像、テキスト中心のページでは見出し付きのテキストブロックがLCP要素となることが多いため、自サイトのLCP要素が何かを正確に把握することが改善の第一歩です。
測定対象
LCPはビューポート内で最も大きく表示されるコンテンツ要素を対象に計測され、画像・動画・テキストブロックなどが含まれます。
ブラウザはLCPの計測にあたり、以下に列挙する特定のHTML要素タイプのみを対象とします。背景画像やCSS疑似要素で挿入されたコンテンツも対象に含まれますが、iframeの中身やSVG内のテキストは現時点では対象外となるため、ページ設計時にはLCP要素がどの要素になるかを意識することが重要です。
- <img> 要素
- <svg> 内の <image> 要素
- <video> 要素(ポスター画像)
- CSS background-image を持つ要素
- テキストノードを含むブロックレベル要素
測定タイミング
ブラウザはページ読み込み中にDOMの変化を追跡し、ユーザーが最初に操作するまでの間で最大のコンテンツ要素を動的に判定します。
LCPの計測はナビゲーション開始時点からスタートし、ユーザーがクリックやタップなどの操作を行った時点で確定します。ページ読み込み中に複数の候補要素が順次表示される場合、ブラウザはそのつどLCP候補を更新し続けるため、遅れて読み込まれる大きな画像がLCP値を悪化させる原因となります。
- ビューポート内で最大の要素
- DOMが変更されるたびに再計算
- ユーザーの操作で計測停止
- 最終的に表示された最大要素で確定
LCP改善の主要戦略
1. サーバーレスポンス時間の最適化
TTFB(Time to First Byte)が遅いとLCPは必ず悪化するため、サーバー側の応答速度はLCP改善の最も基本的な出発点です。
サーバーレスポンス時間はLCPの土台となる指標であり、TTFBが600msを超えるとLCPの2.5秒以内達成が困難になります。CDNの導入によりユーザーとの物理的距離を短縮し、サーバーサイドキャッシュやデータベースクエリの最適化と組み合わせることで、TTFBを200ms以下に抑えることが理想的な目標です。
- CDNの活用でサーバー距離短縮
- キャッシュ戦略の最適化
- サーバーサイドレンダリング(SSR)の活用
- データベースクエリの最適化
Resource Hintsを活用することで、ブラウザが事前に接続やリソース取得を開始でき、TTFBとLCPの両方を改善できます。以下はその実装例です。
<!-- Critical Resource Hints -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="dns-prefetch" href="https://cdn.example.com">
<!-- Hero画像のpreload -->
<link rel="preload" as="image" href="/hero-image.webp">2. 画像最適化
多くのWebページではHero画像がLCP要素となるため、画像のフォーマット変換・圧縮・適切なサイズ指定がLCP改善に最も大きな効果をもたらします。
WebPやAVIFなどの次世代フォーマットはJPEGと比較して同等画質で30〜50%のファイルサイズ削減が可能です。さらにsrcset属性とsizes属性を適切に設定することで、デバイスの画面幅やピクセル密度に応じた最適なサイズの画像を配信でき、無駄なデータ転送を大幅に削減できます。
- 次世代画像フォーマット(WebP, AVIF)の使用
- 適切なサイズとコンプレッション
- レスポンシブ画像の実装
- 遅延読み込みの戦略的使用
以下はpicture要素とWebPフォーマットを組み合わせた最適化画像タグの実装例で、LCP要素となるHero画像に効果的です。
<!-- 最適化された画像タグ -->
<picture>
<source srcset="hero.avif" type="image/avif">
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg"
alt="Hero Image"
width="1200"
height="600"
loading="eager"
decoding="async">
</picture>3. レンダリングブロッキング要素の最適化
CSSやJavaScriptがレンダリングをブロックすると、HTML解析が中断されLCP要素の描画が大幅に遅延するため、クリティカルリソースと非クリティカルリソースを分離する必要があります。
- クリティカルCSS/JSの inline化
- 非クリティカルリソースの遅延読み込み
- JavaScriptの非同期読み込み
- フォントの最適化
レンダリングブロッキングを回避する基本テクニックとして、Critical CSSのinline化と非クリティカルリソースのpreloadを組み合わせた実装例を示します。
<!-- Critical CSS inline -->
<style>
/* Above-the-fold styles */
.hero { display: flex; min-height: 100vh; }
</style>
<!-- Non-critical CSS preload -->
<link rel="preload" href="/css/non-critical.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<!-- Async JavaScript -->
<script src="/js/app.js" async></script>LCP診断ツールと改善手順
LCPの改善はまずボトルネックの正確な特定から始まります。サーバーレスポンス、リソースのダウンロード、レンダリングブロッキングのどの段階で時間がかかっているかを診断ツールで分析し、最も効果の大きい改善ポイントから優先的に対処することで、限られた工数で最大の改善効果を得ることができます。
推奨診断ツール
LCPの問題箇所を特定するには、以下のツールを組み合わせて使用すると、Lab DataとField Dataの両面から詳細な分析ができます。
各ツールには得意分野があり、LighthouseはLab環境での詳細な内訳分析に、PageSpeed InsightsはField Dataとの比較に、WebPageTestはウォーターフォール分析による読み込み順序の最適化にそれぞれ優れています。これらを組み合わせて多角的に分析することで、より正確なボトルネック特定が可能になります。
Lighthouse
包括的なパフォーマンス分析
PageSpeed Insights
リアルユーザーデータ
WebPageTest
詳細な読み込み分析
LCP改善の成功事例
Eコマースサイトの事例:
- Hero画像をWebPフォーマットに変更: LCP 4.2秒 → 2.8秒
- CDN導入とサーバー最適化: 2.8秒 → 2.1秒
- Critical CSSのinline化: 2.1秒 → 1.8秒
- 結果:直帰率15%改善、コンバージョン率12%向上
3. FID(First Input Delay)
FIDは、ユーザーが初めてページと相互作用しようとしてから、ブラウザが実際にその相互作用の処理を開始するまでの遅延時間を測定します。ページの応答性とインタラクティブ性を評価する重要な指標です。
FIDの測定対象
FIDはユーザーの最初の操作に対するブラウザの応答遅延のみを測定するため、ページ内で最も重要な「初回インタラクション」がどのタイミングで発生するかが重要です。多くのユーザーはページ読み込み直後にナビゲーションやボタンクリックを行うため、ページ読み込み初期のメインスレッド占有状況がFIDの値を大きく左右します。
測定されるイベント
FIDはユーザーが意図的に行った離散的な入力操作のみを対象とし、ブラウザがその操作の処理を開始するまでの待ち時間を計測します。
測定対象となるのは、ユーザーが明示的に意図して行うクリック、タップ、キー入力といった離散的な操作イベントです。これらのイベントがメインスレッドのブロッキング中に発生すると、ブラウザは現在のタスク完了まで応答を保留するため、ユーザーは「操作が効かない」という悪い印象を受けることになります。
- クリック
- タップ
- キー押下
- その他の離散的なインタラクション
測定されないイベント
スクロールやズームなどの連続的な操作はFIDの計測対象外です。これらはブラウザが別スレッドで処理できるため、メインスレッドのブロッキングとは直接関係しません。
連続的なインタラクションであるスクロールやピンチズームは、ブラウザのコンポジタースレッドで処理されるためメインスレッドの影響を受けにくく、FIDの計測対象から除外されています。ただし、スクロールにJavaScriptのイベントハンドラが紐づいている場合はメインスレッドの負荷に影響を与えるため、間接的にFIDを悪化させる可能性があります。
- スクロール
- ズーム
- 連続的なインタラクション
FID問題の根本原因
FIDが悪化する最大の原因は、ブラウザのメインスレッドが重いJavaScript処理で長時間占有されることにあります。メインスレッドはJavaScriptの実行、DOMの解析、スタイルの計算、レイアウトなどの処理を順次実行するため、50msを超える長時間タスクが存在するとユーザーの入力に即座に応答できない状態が発生し、これがFID悪化として現れます。
メインスレッドブロッキング
FIDが悪い主な原因は、メインスレッドが重いJavaScript処理でブロックされることです。
典型的なブロッキング要因
ブラウザのメインスレッドは一度に1つのタスクしか処理できないため、50ms以上の長時間タスクがあるとユーザー入力への応答が遅れFIDが悪化します。
Chrome DevToolsのPerformanceパネルでは、50msを超えるタスクが赤いフラグで「Long Task」として可視化されます。特にページ読み込み直後の数秒間に集中するJavaScriptの解析と実行、サードパーティスクリプトの初期化処理がFID悪化の主要因であり、これらの長時間タスクを分割または遅延させることが改善の基本方針となります。
- 巨大なJavaScriptファイルの解析・実行
- 長時間実行される関数
- 第三者スクリプト(広告、分析など)
- 複雑なDOM操作
FID改善戦略
1. JavaScriptの最適化
長時間タスクを小さなチャンクに分割してsetTimeoutで実行すると、メインスレッドが定期的に解放され、ユーザー入力に即座に応答できる状態を維持できます。
JavaScriptの最適化はFID改善において最も効果的なアプローチです。具体的には、ループ処理やデータ変換などの重い計算を小さなチャンクに分割し、各チャンク間でsetTimeoutやrequestIdleCallbackを使ってメインスレッドを解放します。これにより、ユーザーの入力イベントが処理待ちキューに滞留する時間を大幅に短縮できます。
// 悪い例:メインスレッドをブロックする重い処理
function heavyComputation() {
for (let i = 0; i < 1000000; i++) {
// 重い計算処理
}
}
document.addEventListener('click', heavyComputation);
// 良い例:処理を分割してメインスレッドを解放
function heavyComputationOptimized() {
return new Promise(resolve => {
function chunk(start) {
const end = Math.min(start + 1000, 1000000);
for (let i = start; i < end; i++) {
// 処理の一部
}
if (end < 1000000) {
setTimeout(() => chunk(end), 0);
} else {
resolve();
}
}
chunk(0);
});
}
document.addEventListener('click', async () => {
await heavyComputationOptimized();
});2. コード分割とバンドル最適化
初期ロードで必要なJavaScriptのみを読み込み、残りを遅延読み込みにすることで、メインスレッドの占有時間を減らしFIDを大幅に改善できます。
Webpackのコード分割機能やReactのReact.lazy、Vue.jsの非同期コンポーネントなどを活用すると、初期バンドルサイズを大幅に削減できます。理想的には初期読み込みのJavaScriptを170KB以下に抑え、ルートベースまたはコンポーネントベースの分割によって必要な機能だけをオンデマンドで読み込む設計にすることが推奨されます。
- 動的インポートによる遅延読み込み
- ツリーシェイキングで未使用コードを除去
- Webpackのチャンク分割設定
- Service Workerによるリソースキャッシュ
動的インポートを活用すると、必要な機能のコードを実際に使用する直前に読み込むため、初期バンドルサイズを大幅に削減しFIDを改善できます。
// 動的インポートの例
document.addEventListener('click', async (e) => {
if (e.target.classList.contains('chart-button')) {
const { ChartLibrary } = await import('./chart-library.js');
new ChartLibrary().render();
}
});
// Webpack設定例(webpack.config.js)
module.exports = {
optimization: {
splitChunks: {
chunks: 'all',
cacheGroups: {
vendor: {
test: /[\/]node_modules[\/]/,
name: 'vendors',
chunks: 'all',
},
},
},
},
};3. Web Workersの活用
Web Workersを使うとデータの加工や画像処理などの重い計算をバックグラウンドスレッドで実行でき、メインスレッドがユーザー操作に即座に応答できる状態を保てます。
- CPU集約的な処理をメインスレッドから分離
- バックグラウンドでのデータ処理
- 画像処理やデータ変換の最適化
Web Workersを使った実装例で、重い計算処理をバックグラウンドスレッドに移すことでメインスレッドが常にユーザー入力に応答可能な状態を維持します。
// メインスレッド (main.js)
const worker = new Worker('worker.js');
document.addEventListener('click', () => {
worker.postMessage({ data: largeDataSet });
});
worker.onmessage = (e) => {
// 結果を受信してUIを更新
updateUI(e.data.result);
};
// Web Worker (worker.js)
self.onmessage = function(e) {
const result = processLargeDataSet(e.data.data);
self.postMessage({ result });
};4. CLS(Cumulative Layout Shift)
CLSは、ページの読み込み中に発生する予期しないレイアウト移動の累積を測定します。ユーザーが意図しないクリックをしてしまうような、視覚的な安定性の問題を特定します。
CLSの計算方法
CLSのスコアは「Impact Fraction × Distance Fraction」の計算式で算出され、移動した要素の大きさと移動距離の両方が影響します。
- Impact Fraction: 移動した要素がビューポートに占める割合
- Distance Fraction: 最大移動距離のビューポートに対する割合
CLSを引き起こす要因
レイアウトシフトは、ブラウザがリソースの読み込み完了後にページ上の要素の位置やサイズを再計算する際に発生し、ユーザーの意図しない誤クリックを引き起こします。
レイアウトシフトが発生する根本的な原因は、ブラウザが要素の最終的なサイズや位置を事前に把握できないことにあります。画像のwidthとheight属性が省略されている場合、広告枠のサイズが動的に決まる場合、Webフォントの読み込みによりテキストのサイズが変わる場合など、リソースの読み込み完了時にレイアウトの再計算が発生しページ全体が移動します。
- サイズが指定されていない画像
- サイズが指定されていない広告
- 動的に挿入されるコンテンツ
- Web フォントの読み込み
- ネットワークレスポンス待ちのアクション
CLS改善のメリット
レイアウトの安定性を確保することで、ユーザーは安心してページを操作でき、フォーム送信や購入ボタンのクリックなど重要なアクションの完了率が向上します。
CLS改善は直接的にユーザビリティを向上させ、特にEコマースサイトでは「購入ボタンを押そうとしたら広告が表示されて別のリンクをクリックしてしまった」といった誤操作を防止することで、カート放棄率の低減とコンバージョン率の改善に直結します。また、Google検索でのランキング評価も向上するため、SEOとUXの両面で大きなメリットがあります。
- ユーザビリティの向上
- 誤クリック率の減少
- コンバージョン率の改善
- ユーザー満足度の向上
- SEO評価の向上
CLS改善の実践的手法
1. 画像とメディア要素の最適化
画像にwidth/heightまたはaspect-ratioを指定すると、ブラウザは画像読み込み前にレイアウト領域を確保でき、レイアウトシフトを防止できます。
HTML5のwidth/height属性を指定すると、モダンブラウザは自動的にアスペクト比を計算してレイアウト領域を事前確保します。CSS aspect-ratioプロパティを併用するとレスポンシブデザインでも比率を維持でき、動画やiframeなどのメディア要素にも同様のテクニックを適用することで、ページ全体のレイアウト安定性を確保できます。
<!-- 悪い例:サイズ指定なし -->
<img src="image.jpg" alt="Sample Image">
<!-- 良い例:width/height指定 -->
<img src="image.jpg"
alt="Sample Image"
width="800"
height="600">
<!-- さらに良い例:aspect-ratioでレスポンシブ対応 -->
<img src="image.jpg"
alt="Sample Image"
style="aspect-ratio: 4/3; width: 100%; height: auto;">
<!-- CSS aspect-ratio property -->
<style>
.responsive-image {
aspect-ratio: 16 / 9;
width: 100%;
height: auto;
}
</style>2. 動的コンテンツの空間予約
広告や動的コンテンツの読み込み領域を事前にmin-heightで確保すると、コンテンツ挿入時のレイアウトシフトを完全に防げます。
広告バナー、ニュースフィード、レコメンデーションウィジェットなど、サーバーからのレスポンスを待って動的に挿入されるコンテンツは、CLS悪化の最大要因の一つです。これらの領域にmin-heightやaspect-ratioを設定してプレースホルダーを表示することで、コンテンツ読み込み後のレイアウトシフトをゼロに近づけることが可能です。
/* 広告スペースの事前確保 */
.ad-container {
min-height: 250px;
display: flex;
align-items: center;
justify-content: center;
background-color: #f5f5f5;
}
.ad-container::before {
content: "広告読み込み中...";
color: #999;
}
/* 動的コンテンツのプレースホルダー */
.content-placeholder {
height: 200px;
background: linear-gradient(90deg, #f0f0f0 25%, #e0e0e0 50%, #f0f0f0 75%);
background-size: 200% 100%;
animation: loading 1.5s infinite;
}
@keyframes loading {
0% { background-position: 200% 0; }
100% { background-position: -200% 0; }
}3. フォント読み込みの最適化
Webフォントの読み込み遅延によるテキストサイズ変化を防ぐため、preloadとfont-display: swapを組み合わせてフォールバックフォントとのサイズを調整します。
<!-- フォントの事前読み込み -->
<link rel="preload" href="/fonts/custom-font.woff2" as="font" type="font/woff2" crossorigin>
<style>
/* font-display: swap でFOUTを最小化 */
@font-face {
font-family: 'CustomFont';
src: url('/fonts/custom-font.woff2') format('woff2');
font-display: swap;
}
/* フォールバックフォントとのサイズ調整 */
@font-face {
font-family: 'CustomFont';
src: url('/fonts/custom-font.woff2') format('woff2');
font-display: swap;
ascent-override: 90%;
descent-override: 22%;
line-gap-override: 0%;
size-adjust: 100%;
}
</style>4. アニメーションの最適化
アニメーションでheightやwidthを変更するとレイアウトシフトが発生するため、transformやopacityを使うことで視覚効果を保ちつつCLSを回避できます。
/* 悪い例:layout propertiesの変更 */
.bad-animation {
transition: height 0.3s ease;
}
.bad-animation:hover {
height: 200px; /* レイアウト移動を引き起こす */
}
/* 良い例:transform/opacityの使用 */
.good-animation {
height: 100px;
transform: scaleY(1);
transition: transform 0.3s ease;
}
.good-animation:hover {
transform: scaleY(2); /* レイアウト移動なし */
}
/* さらに良い例:will-changeでパフォーマンス最適化 */
.optimized-animation {
will-change: transform;
transform: translateY(0);
transition: transform 0.3s ease;
}
.optimized-animation:hover {
transform: translateY(-10px);
}CLS デバッグと監視
開発時のデバッグ
開発中はLab Data環境でレイアウトシフトの発生箇所を視覚的に特定し、原因となる要素を1つずつ修正していくアプローチが効果的です。
Chrome DevToolsのPerformanceパネルでは「Layout Shift」イベントが記録され、どの要素がどの程度移動したかを視覚的に確認できます。また、Rendering設定で「Layout Shift Regions」を有効にすると、レイアウトシフトが発生するたびに画面上で青色のハイライトが表示されるため、問題の発生箇所をリアルタイムで特定しながら修正作業を進められます。
- Chrome DevTools Performance パネル
- Layout Shift Regions の可視化
- Lighthouse のCLS分析
- Web Vitals Chrome 拡張機能
本番環境の監視
本番環境では実際のユーザーのデバイスやネットワーク条件でのCLS値をField Dataとして収集し、Lab Dataでは検出できない問題を把握することが重要です。
- Real User Monitoring (RUM)
- Google Analytics 4 Web Vitals
- Search Console Core Web Vitals
- カスタムCLS追跡スクリプト
以下はPerformanceObserver APIを使ってCLSをリアルタイムで追跡し、Google Analyticsに送信するスクリプト例です。
// カスタムCLS監視スクリプト
function observeCLS() {
let clsValue = 0;
const observer = new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntries()) {
if (!entry.hadRecentInput) {
clsValue += entry.value;
console.log('CLS:', clsValue);
// Analytics に送信
gtag('event', 'cumulative_layout_shift', {
value: Math.round(clsValue * 1000),
metric_value: clsValue
});
}
}
});
observer.observe({ entryTypes: ['layout-shift'] });
}
// ページロード時にCLS監視を開始
if ('PerformanceObserver' in window) {
observeCLS();
}5. 測定方法とツール
Core Web Vitalsの測定には、実験室データ(Lab Data)と実際のユーザーデータ(Field Data)の両方を活用することが重要です。それぞれの特徴を理解して、適切な測定・改善サイクルを構築しましょう。
測定データの種類
Lab Data(実験室データ)
Lab DataはLighthouseなどのツールが固定のネットワーク・デバイス条件で計測するデータで、問題の原因特定やコード変更前後の比較に適しています。
Lab Dataの最大の利点は再現性にあり、同一条件で繰り返し計測できるため、コード変更の前後でパフォーマンスの差分を正確に測定できます。一方で、実際のユーザー環境の多様性(低速デバイス、不安定なネットワーク等)を反映しないため、Field Dataとの乖離が生じることがあります。開発・デバッグフェーズではLab Data、本番評価ではField Dataを使い分けることが重要です。
- 統制された環境での測定
- 再現可能で一貫した結果
- 開発・デバッグに最適
- 仮想的なユーザー環境
主なツール: Lighthouse, WebPageTest, Chrome DevTools
Field Data(実ユーザーデータ)
Field Dataは実際のユーザーのブラウザから収集されるRUM(Real User Monitoring)データで、Googleの検索ランキング評価に使用されるのはこちらのデータです。
- 実際のユーザー体験データ
- 多様な環境・デバイス
- SEOランキングに直接影響
- 長期的なトレンド分析
主なツール: Chrome User Experience Report, PageSpeed Insights, Search Console
主要な測定ツール
Google Lighthouse
Googleが開発したオープンソースのWebパフォーマンス監査ツールで、Chrome DevToolsやCLIから実行でき、改善提案付きの詳細レポートを生成します。
- 包括的なパフォーマンス分析
- 具体的な改善提案
- CI/CDパイプラインとの統合
- 継続的な監視が可能
Lighthouseはコマンドラインから実行できるため、CI/CDパイプラインに組み込んで継続的にパフォーマンスを監視できます。
# CLI での Lighthouse 実行
npm install -g lighthouse
lighthouse https://example.com --output=html
# CI/CD での自動実行
lighthouse https://example.com --output=json --quietPageSpeed Insights
Googleが提供する公式パフォーマンス測定ツールで、Lab DataとField Dataの両方をワンクリックで取得できます。
PageSpeed InsightsはCrUX(Chrome User Experience Report)のField DataとLighthouseのLab Dataを統合した唯一の公式ツールであり、URLを入力するだけで両方のデータを同時に取得できます。API経由での自動取得にも対応しているため、社内ダッシュボードへの組み込みや定期的な監視の自動化にも活用できます。
- Lab Data と Field Data の両方提供
- CrUX データベースとの連携
- モバイル・デスクトップ別分析
- API での自動取得が可能
PageSpeed Insights APIを使うと、Core Web Vitalsデータを自動取得してダッシュボードに統合できます。以下は実装例です。
// PageSpeed Insights API 使用例
const API_KEY = 'YOUR_API_KEY';
const url = 'https://example.com';
fetch(`https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=${url}&key=${API_KEY}&category=performance`)
.then(response => response.json())
.then(data => {
const metrics = data.lighthouseResult.audits;
console.log('LCP:', metrics['largest-contentful-paint'].displayValue);
console.log('FID:', metrics['max-potential-fid'].displayValue);
console.log('CLS:', metrics['cumulative-layout-shift'].displayValue);
});Google Search Console
実ユーザーのCore Web Vitals体験データをURL単位・デバイス別に確認でき、改善が必要なページを優先度順に特定できます。
Search Consoleの「ウェブに関する主な指標」レポートでは、サイト全体のURL群が「良好」「改善が必要」「不良」の3カテゴリに分類され、問題のあるURLグループを一覧で確認できます。28日間のField Dataに基づいているため実際のSEO評価と直結しており、改善後の効果反映にも数週間を要することを考慮した計画的な改善が必要です。
- 28日間の実ユーザーデータ
- URL別・デバイス別の詳細分析
- 改善が必要なページの特定
- SEOインパクトとの関連性
継続的監視システムの構築
PerformanceObserver APIを活用してLCP、FID、CLSの3指標をリアルタイムで監視し、分析サービスに送信する統合監視システムの実装例です。
// リアルタイムWeb Vitals監視システム
class WebVitalsMonitor {
constructor() {
this.metrics = {};
this.setupObservers();
}
setupObservers() {
// LCP 測定
new PerformanceObserver((entryList) => {
const entries = entryList.getEntries();
const lastEntry = entries[entries.length - 1];
this.metrics.lcp = lastEntry.startTime;
this.sendMetric('LCP', lastEntry.startTime);
}).observe({ entryTypes: ['largest-contentful-paint'] });
// FID 測定
new PerformanceObserver((entryList) => {
const entries = entryList.getEntries();
entries.forEach(entry => {
this.metrics.fid = entry.processingStart - entry.startTime;
this.sendMetric('FID', this.metrics.fid);
});
}).observe({ entryTypes: ['first-input'] });
// CLS 測定
let clsValue = 0;
new PerformanceObserver((entryList) => {
entries.forEach(entry => {
if (!entry.hadRecentInput) {
clsValue += entry.value;
this.metrics.cls = clsValue;
this.sendMetric('CLS', clsValue);
}
});
}).observe({ entryTypes: ['layout-shift'] });
}
sendMetric(name, value) {
// アナリティクスサービスに送信
gtag('event', 'web_vitals', {
metric_name: name,
metric_value: Math.round(value),
page_url: window.location.href
});
// カスタム監視エンドポイントに送信
fetch('/api/metrics', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
metric: name,
value: value,
url: window.location.href,
timestamp: Date.now(),
userAgent: navigator.userAgent
})
});
}
}
// 監視開始
const monitor = new WebVitalsMonitor();6. 最適化テクニック
Core Web Vitalsの改善は単発の取り組みではなく、継続的な最適化プロセスです。効果的なテクニックを体系的に適用し、持続可能な改善を実現しましょう。
フロントエンド最適化
フロントエンド最適化は、ブラウザがHTML・CSS・JavaScriptを受け取ってから画面に描画するまでの全プロセスを対象とする包括的な改善アプローチです。リソースの読み込み順序の最適化、レンダリングパイプラインの効率化、JavaScriptの実行負荷軽減という3つの柱で構成され、LCP・FID・CLSの全指標に横断的な改善効果をもたらします。
リソース最適化
Resource Hintsを効果的に使うと、ブラウザが事前にDNS解決や重要リソースの取得を開始し、LCPを大幅に改善できます。
preconnect、dns-prefetch、preload、prefetchの4つのResource Hintsをページの特性に合わせて使い分けることが重要です。特にサードパーティのフォントやCDNリソースにはpreconnectを、LCP要素となるHero画像にはpreloadを設定することで、リソース取得の待ち時間を数百ms単位で短縮できます。
<!-- Critical Resource Hints の活用 -->
<head>
<!-- DNS預解析 -->
<link rel="dns-prefetch" href="//fonts.googleapis.com">
<link rel="dns-prefetch" href="//cdn.example.com">
<!-- 重要リソースのpreload -->
<link rel="preload" href="/fonts/main.woff2" as="font" type="font/woff2" crossorigin>
<link rel="preload" href="/css/critical.css" as="style">
<link rel="preload" href="/js/critical.js" as="script">
<!-- 次ページのprefetch -->
<link rel="prefetch" href="/next-page.html">
<!-- 重要画像のpreload -->
<link rel="preload" href="/hero-image.webp" as="image">
</head>レンダリング最適化
Critical CSSをインライン化し、スクロールせずに見える領域のスタイルを優先的に適用することで、First Paintを高速化しLCPを改善できます。
レンダリング最適化の中心はCSSの配信戦略にあります。ファーストビューに必要なスタイルだけをHTMLのstyleタグにインライン記述し、残りのCSSをpreloadで非同期に読み込むことで、CSSファイルによるレンダリングブロッキングを排除できます。さらにCSS Containmentプロパティを活用すると、各コンポーネントの再レイアウト範囲を限定し描画パフォーマンスが向上します。
/* Critical CSS(Above the fold) */
.header, .hero, .main-nav {
/* 即座に表示される要素のスタイル */
}
/* 非クリティカルCSS読み込み */
<link rel="preload" href="/css/below-fold.css" as="style"
onload="this.onload=null;this.rel='stylesheet'">
/* CSS Containment でレンダリング範囲を制限 */
.component {
contain: layout style paint;
}
.isolated-widget {
contain: strict;
}
/* Intersection Observer でlazy loading */
.lazy-element {
opacity: 0;
transition: opacity 0.3s;
}
.lazy-element.loaded {
opacity: 1;
}JavaScript最適化
JavaScriptの遅延読み込みと非同期処理の最適化により、メインスレッドの占有時間を削減しFIDを改善する実装パターンです。
JavaScriptは解析・コンパイル・実行のすべての段階でメインスレッドを占有するため、バンドルサイズの削減と実行タイミングの最適化がFID改善の要です。React.lazyやdynamic import()による遅延読み込み、Intersection Observerを使った表示範囲に応じた段階的な機能有効化など、必要なときに必要な分だけ処理を実行する設計パターンを徹底することが重要です。
// バンドル分割とlazy loading
const ComponentA = lazy(() => import('./ComponentA'));
const ComponentB = lazy(() => import('./ComponentB'));
// 非同期処理の最適化
function optimizeAsyncWork() {
return new Promise(resolve => {
function processChunk(startIndex) {
const endIndex = Math.min(startIndex + 100, totalItems);
for (let i = startIndex; i < endIndex; i++) {
// 処理実行
}
if (endIndex < totalItems) {
// メインスレッドを解放して次のチャンクを処理
setTimeout(() => processChunk(endIndex), 0);
} else {
resolve();
}
}
processChunk(0);
});
}
// Intersection Observer の効率的な使用
const imageObserver = new IntersectionObserver((entries) => {
entries.forEach(entry => {
if (entry.isIntersecting) {
const img = entry.target;
img.src = img.dataset.src;
img.classList.remove('lazy');
imageObserver.unobserve(img);
}
});
}, {
rootMargin: '50px 0px',
threshold: 0.1
});サーバーサイド最適化
キャッシュ戦略
適切なキャッシュ戦略はサーバーへのリクエスト回数を削減し、リピートユーザーのLCPを劇的に改善します。静的リソースには長いキャッシュ期間を設定し、動的コンテンツにはrevalidation戦略を採用するのが基本です。
- HTTP Cache Headers の最適化
- CDN による静的コンテンツ配信
- Service Worker キャッシング
- サーバーサイドキャッシュ
圧縮と配信
転送データ量の削減はネットワーク帯域の限られたモバイル環境で特に効果が大きく、Brotli圧縮はGzipと比較してテキストリソースを15〜25%追加で圧縮できます。
- Gzip/Brotli 圧縮
- 画像の最適化と変換
- HTTP/2 Push の活用
- Edge Computing の活用
Service Workerでキャッシュ戦略を実装すると、リピートユーザーのCore Web Vitalsが劇的に改善され、オフライン対応も可能になります。
// Service Worker キャッシュ戦略
const CACHE_NAME = 'v1';
const urlsToCache = [
'/css/critical.css',
'/js/critical.js',
'/images/hero.webp'
];
self.addEventListener('install', event => {
event.waitUntil(
caches.open(CACHE_NAME)
.then(cache => cache.addAll(urlsToCache))
);
});
self.addEventListener('fetch', event => {
event.respondWith(
caches.match(event.request)
.then(response => {
// キャッシュがあれば返す、なければネットワークから取得
return response || fetch(event.request);
}
)
);
});パフォーマンス予算
パフォーマンス予算とは、ページサイズやリソース数、指標値に上限を設けることで、新機能追加時の回帰を防ぎ継続的な品質維持を実現する仕組みです。
パフォーマンス予算を設定する際は、競合サイトのベンチマークと自サイトの現状値を基に現実的かつ挑戦的な目標を定めます。予算はCI/CDパイプラインに組み込んで自動チェックすることで、新機能の追加やライブラリの更新によるパフォーマンス回帰を開発段階で検出でき、本番環境への悪影響を未然に防止できます。
予算例
パフォーマンス予算はチーム全体で共有する数値基準で、新機能追加時に回帰を防ぐための明確な指針となります。
以下の予算例は一般的なWebサイトを想定した基準値です。サイトの種類によって適切な値は異なりますが、特にJavaScriptバンドルサイズの制限はFIDに、総ダウンロードサイズの制限はLCPにそれぞれ強く影響するため、これらの予算を厳守することがCore Web Vitals達成への近道となります。
| カテゴリ | 制限値 | 監視ツール |
|---|---|---|
| 総ダウンロードサイズ | < 2MB | Lighthouse CI |
| JavaScript バンドル | < 500KB | Webpack Bundle Analyzer |
| LCP | < 2.5秒 | Real User Monitoring |
| CLS | < 0.1 | Layout Shift Monitor |
7. モバイル最適化
モバイルデバイスでのCore Web Vitalsは、デスクトップよりも挑戦的です。限られたCPUとネットワーク帯域を考慮した特別な最適化戦略が必要です。
モバイル特有の課題
モバイル環境ではハードウェア性能、ネットワーク品質、ユーザー行動の3つの側面でデスクトップと大きく異なる制約が存在します。
モバイルデバイスはデスクトップと比較してCPU性能が3〜5倍劣り、メモリ容量も限られているため、同じJavaScriptコードでも実行時間が数倍に膨れ上がります。さらに4G/5G環境でも基地局との距離や混雑状況により通信品質が大きく変動するため、リソースのダウンロード時間の予測が困難です。これらの制約を前提にした設計が不可欠です。
ハードウェア制限
低速CPU、限られたメモリ、バッテリー消費、熱制御
ネットワーク制限
不安定な接続、低帯域幅、高レイテンシー、データ使用制限
ユーザー行動
移動中の使用、断続的な利用、タッチ操作、小さい画面
モバイルデバイスのCPU処理能力はデスクトップの3〜5分の1程度であり、JavaScript実行時間がそのまま数倍に膨らむことがFID悪化の主因となります。
モバイル回線は接続の安定性と帯域幅がデスクトップと比べて大きく劣り、特に3G環境ではリソースダウンロード時間がLCPのボトルネックになりやすくなります。
モバイルユーザーは隙間時間に短時間で情報を得ようとするため、表示遅延やレイアウトの崩れに対する忍耐力がデスクトップユーザーより低い傾向にあります。
モバイル最適化戦略
モバイル最適化戦略はデスクトップ向けの最適化とは異なるアプローチが必要です。ネットワーク状況に応じたアダプティブ配信、タッチ操作に最適化したUI設計、プログレッシブな読み込み体験の3つを柱として、限られたリソース環境でも優れたユーザー体験を提供する設計を目指します。
アダプティブ配信
Network Information APIを使ってユーザーの回線品質を検出し、それに応じて画像品質やコンテンツの量を動的に調整する実装例です。
アダプティブ配信とは、ユーザーのネットワーク接続品質やデバイス性能をリアルタイムに検出し、配信するリソースの品質や量を動的に調整する手法です。高速回線では高解像度画像やリッチなインタラクションを提供し、低速回線では軽量版のコンテンツに切り替えることで、どのユーザーにも最適な体験を提供できます。
// ネットワーク状況に応じた最適化
function getNetworkQuality() {
if ('connection' in navigator) {
const connection = navigator.connection;
return {
effectiveType: connection.effectiveType,
downlink: connection.downlink,
rtt: connection.rtt,
saveData: connection.saveData
};
}
return null;
}
// 品質に応じたリソース配信
function optimizeForConnection() {
const network = getNetworkQuality();
if (!network) return;
if (network.saveData || network.effectiveType === 'slow-2g') {
// データセーバーモード
document.body.classList.add('data-saver');
disableNonEssentialFeatures();
} else if (network.effectiveType === '3g') {
// 中品質モード
loadMediumQualityImages();
} else {
// 高品質モード
loadHighQualityImages();
}
}
// レスポンシブ画像の動的調整
function setupAdaptiveImages() {
const images = document.querySelectorAll('img[data-responsive]');
const network = getNetworkQuality();
images.forEach(img => {
let quality = 'high';
if (network?.effectiveType === '2g' || network?.effectiveType === 'slow-2g') {
quality = 'low';
} else if (network?.effectiveType === '3g') {
quality = 'medium';
}
img.src = img.dataset[`src${quality.charAt(0).toUpperCase() + quality.slice(1)}`];
});
}タッチ最適化
モバイルのタッチ操作に最適化したUIを実装することで、FIDを改善しユーザー体験を向上させられます。iOSは最小44pxを推奨しています。
タッチ操作はマウス操作と異なり指先の接触面積が大きく精度が低いため、タップターゲットには十分なサイズとマージンが必要です。Apple Human Interface Guidelinesは最小44pt、Material Designは48dpを推奨しています。また、touch-action: manipulationの設定によりダブルタップのズーム遅延(300ms)を排除でき、FIDの体感速度を大きく改善できます。
/* タッチフレンドリーなインターフェース */
.touch-target {
min-height: 44px; /* iOS推奨最小サイズ */
min-width: 44px;
margin: 8px; /* タップ誤差を考慮 */
}
/* タッチ応答性の向上 */
.button {
touch-action: manipulation; /* ダブルタップズーム無効化 */
user-select: none; /* テキスト選択防止 */
}
/* スムーズスクロール */
.scroll-container {
-webkit-overflow-scrolling: touch;
scroll-behavior: smooth;
}
/* タッチイベント最適化 */
.interactive-element {
will-change: transform; /* GPU acceleration */
transform: translateZ(0); /* 合成レイヤー作成 */
}プログレッシブ読み込み
低画質版を即座に表示して高画質版をバックグラウンドで読み込むことで、体感速度を大幅に改善しLCPの印象を向上できます。
プログレッシブ読み込みはユーザーの体感速度を向上させる強力なテクニックで、まず数KBのぼかし画像やプレースホルダーを瞬時に表示し、その後バックグラウンドで高解像度版を読み込んでシームレスに差し替えます。この手法はMediumやPinterestなどの大規模サービスでも採用されており、LCPの数値自体は変わらなくてもユーザーの待機感を大幅に軽減できます。
// プログレッシブ画像読み込み
class ProgressiveImageLoader {
constructor(imageElement) {
this.img = imageElement;
this.lowQualitySrc = this.img.dataset.lowres;
this.highQualitySrc = this.img.dataset.highres;
this.loadProgressive();
}
loadProgressive() {
// 1. 低画質版を即座に表示
this.img.src = this.lowQualitySrc;
this.img.style.filter = 'blur(5px)';
// 2. 高画質版をバックグラウンドで読み込み
const highQualityImg = new Image();
highQualityImg.onload = () => {
this.img.src = this.highQualitySrc;
this.img.style.filter = 'blur(0)';
this.img.style.transition = 'filter 0.3s ease';
};
highQualityImg.src = this.highQualitySrc;
}
}
// Intersection Observer と組み合わせ
const imageObserver = new IntersectionObserver((entries) => {
entries.forEach(entry => {
if (entry.isIntersecting) {
new ProgressiveImageLoader(entry.target);
imageObserver.unobserve(entry.target);
}
});
}, {
rootMargin: '50px',
threshold: 0.1
});
document.querySelectorAll('img[data-progressive]').forEach(img => {
imageObserver.observe(img);
});モバイル最適化の成功例
モバイル特化ECサイト:
- アダプティブ画像配信でLCP 4.8秒 → 2.2秒
- タッチ最適化でFID 180ms → 85ms
- Progressive loading でCLS 0.18 → 0.08
- 結果:モバイルコンバージョン率25%向上
8. 継続的モニタリング
Core Web Vitalsの改善は一度きりの作業ではありません。継続的なモニタリングシステムを構築し、パフォーマンスの回帰を防ぎ、持続的な改善を実現しましょう。
監視システムアーキテクチャ
Core Web Vitalsの継続的な監視を実現するには、単一のツールに依存するのではなく、リアルタイムのRUMデータ収集、定期的なLab環境での監査、閾値超過時の自動アラート、長期トレンドの可視化という複数のレイヤーを組み合わせた包括的なアーキテクチャを構築することが推奨されます。
多層監視アプローチ
効果的な監視システムは、リアルタイム監視・定期監査・アラート・トレンド分析の4層で構成され、異常を即座に検知して長期的な改善を推進します。
リアルタイム監視層ではPerformanceObserver APIを使ってユーザーのブラウザから直接データを収集し、定期監査層ではLighthouse CIによる自動テストを実施します。アラート層は閾値を超えた場合にSlackやPagerDutyへ即座に通知を送り、トレンド分析層ではダッシュボードで週次・月次の傾向を可視化して中長期的な改善方針の策定に活用します。
1. リアルタイム監視
ユーザー体験の即座把握
2. 定期的監査
自動化されたテスト
3. アラート システム
異常値の早期発見
4. トレンド分析
長期的な変化の把握
PerformanceObserverと定期監査を組み合わせた包括的な監視システムの実装例で、異常値の自動検出と通知を実現します。
// 包括的な監視システム
class CoreWebVitalsMonitor {
constructor(config) {
this.config = config;
this.metrics = new Map();
this.alerts = [];
this.setupRealtimeMonitoring();
this.setupPeriodicAudits();
}
setupRealtimeMonitoring() {
// リアルタイム RUM データ収集
const observer = new PerformanceObserver((entryList) => {
const entries = entryList.getEntries();
entries.forEach(entry => {
this.recordMetric(entry.entryType, entry);
this.checkThresholds(entry.entryType, entry.value);
});
});
observer.observe({ entryTypes: ['largest-contentful-paint', 'first-input', 'layout-shift'] });
}
setupPeriodicAudits() {
// 定期的な Lighthouse 監査
setInterval(async () => {
const auditResults = await this.runLighthouseAudit();
this.compareWithBaseline(auditResults);
this.updateTrends(auditResults);
}, this.config.auditInterval);
}
checkThresholds(metricType, value) {
const threshold = this.config.thresholds[metricType];
if (value > threshold) {
this.triggerAlert(metricType, value, threshold);
}
}
triggerAlert(metric, value, threshold) {
const alert = {
timestamp: Date.now(),
metric,
value,
threshold,
severity: this.calculateSeverity(value, threshold)
};
this.alerts.push(alert);
this.sendNotification(alert);
}
async sendNotification(alert) {
// Slack/Email/PagerDuty等への通知
await fetch('/api/alerts', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify(alert)
});
}
}
// 監視システム初期化
const monitor = new CoreWebVitalsMonitor({
auditInterval: 1800000, // 30分ごと
thresholds: {
'largest-contentful-paint': 2500,
'first-input': 100,
'layout-shift': 0.1
}
});CI/CD統合
開発プロセスにパフォーマンステストを組み込むことで、プルリクエストの段階でCore Web Vitalsの回帰を自動検出し、品質低下を未然に防ぐ仕組みを構築できます。
GitHub ActionsでLighthouse CIを実行し、プルリクエストごとにCore Web Vitalsを自動チェックする設定例です。
# GitHub Actions でのCore Web Vitals チェック
name: Performance Check
on:
pull_request:
branches: [main]
jobs:
lighthouse:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Setup Node.js
uses: actions/setup-node@v2
with:
node-version: '16'
- name: Install dependencies
run: npm ci
- name: Build site
run: npm run build
- name: Serve site
run: npm run serve &
- name: Run Lighthouse CI
run: |
npm install -g @lhci/cli@0.9.x
lhci autorun
env:
LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}
- name: Check Core Web Vitals
run: |
node scripts/check-cwv-thresholds.js
# パフォーマンス予算チェック
bundle-size:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Check bundle size
uses: andresz1/size-limit-action@v1
with:
github_token: ${{ secrets.GITHUB_TOKEN }}ダッシュボードとレポート
パフォーマンスデータの可視化は、開発チーム全体がCore Web Vitalsの現状と改善効果を共有し、データに基づいた意思決定を行うために不可欠です。リアルタイムダッシュボードで日常的な監視を行い、定期レポートで中長期のトレンド分析と戦略的な改善計画の策定を支援する二層構造が効果的です。
リアルタイムダッシュボード
リアルタイムダッシュボードにより、デプロイ直後のパフォーマンス回帰やトラフィック急増時の指標悪化を即座に検知し、迅速な対応が可能になります。
リアルタイムダッシュボードはGrafana、Datadog、Google Looker Studioなどのツールで構築でき、LCP・FID・CLSの現在値をリアルタイムに表示します。目標閾値のラインを重ねて表示することで改善状況を一目で把握でき、デプロイ後のパフォーマンス回帰を数分以内に検知してロールバック判断を迅速に行える体制を構築できます。
- 現在の Core Web Vitals 値
- トラフィック量との相関
- デバイス・地域別分析
- アラート状況
週次/月次レポート
定期レポートでは中長期のトレンドを分析し、改善施策の効果を数値で評価することで、チーム内でのパフォーマンス意識の定着とROIの可視化を実現します。
週次レポートでは直近のデプロイによる影響や短期的な変動を確認し、月次レポートでは季節変動やトラフィック増減を考慮した長期トレンドの分析を行います。競合サイトとのベンチマーク比較や、改善施策ごとのROI算出を含めることで、経営層への報告資料としても活用でき、パフォーマンス改善への投資判断の根拠を提供できます。
- トレンド分析と前期比較
- 改善施策の効果測定
- 競合他社との比較
- 次期改善提案
Chart.jsを使ってLCP、FID、CLSのリアルタイムトレンドをグラフ表示し、目標値を可視化するダッシュボード実装例です。
// ダッシュボード用データ可視化
class WebVitalsDashboard {
constructor(containerId) {
this.container = document.getElementById(containerId);
this.charts = {};
this.setupCharts();
this.startRealtimeUpdates();
}
setupCharts() {
// LCP トレンドチャート
this.charts.lcp = new Chart(this.container.querySelector('#lcp-chart'), {
type: 'line',
data: {
labels: [],
datasets: [{
label: 'LCP (ms)',
data: [],
borderColor: 'rgb(59, 130, 246)',
backgroundColor: 'rgba(59, 130, 246, 0.1)'
}]
},
options: {
responsive: true,
scales: {
y: {
beginAtZero: true,
max: 4000,
title: {
display: true,
text: 'Time (ms)'
}
}
},
plugins: {
annotation: {
annotations: {
goodThreshold: {
type: 'line',
yMin: 2500,
yMax: 2500,
borderColor: 'green',
borderWidth: 2,
label: {
content: 'Good (≤2.5s)',
enabled: true
}
}
}
}
}
}
});
}
startRealtimeUpdates() {
// WebSocket またはポーリングでリアルタイム更新
setInterval(async () => {
const metrics = await this.fetchLatestMetrics();
this.updateCharts(metrics);
this.updateSummaryCards(metrics);
}, 30000); // 30秒ごと
}
async fetchLatestMetrics() {
const response = await fetch('/api/metrics/latest');
return response.json();
}
updateCharts(metrics) {
// チャートデータの更新
Object.keys(this.charts).forEach(metric => {
if (metrics[metric]) {
this.charts[metric].data.labels.push(new Date().toLocaleTimeString());
this.charts[metric].data.datasets[0].data.push(metrics[metric]);
// 最新50ポイントのみ保持
if (this.charts[metric].data.labels.length > 50) {
this.charts[metric].data.labels.shift();
this.charts[metric].data.datasets[0].data.shift();
}
this.charts[metric].update();
}
});
}
}
// ダッシュボード初期化
const dashboard = new WebVitalsDashboard('cwv-dashboard');9. 改善事例
実際のCore Web Vitals改善プロジェクトの事例を通じて、効果的なアプローチとその成果を学びましょう。
事例1:大規模メディアサイト
月間PV数500万を超える大規模メディアサイトにおけるCore Web Vitals改善プロジェクトの事例です。記事ページ中心のコンテンツ構成で、広告収益モデルのため多数の広告ユニットが配置されており、画像リッチな記事コンテンツと広告の両立がパフォーマンス改善における最大の課題でした。
改善前の状況
大量の広告と未最適化の画像により、全3指標がGoogleの「不良」基準を超えており、モバイル検索での順位が競合サイトに大きく劣っていました。
改善前の状態ではモバイルページの90%以上が「不良」判定を受けており、特にLCPは未圧縮のJPEG画像とレンダリングブロッキングするCSSにより6秒を超える状態でした。広告スクリプトの同期読み込みがFIDを悪化させ、サイズ未指定の広告枠がCLSを引き起こすという、典型的な問題が複合的に発生していました。
- LCP: 6.2秒
- FID: 280ms
- CLS: 0.35
- モバイル順位低下
- 直帰率65%
実施した改善
LCPに最も影響の大きい画像最適化から着手し、段階的にJavaScript分割とCSS最適化を実施することで、各フェーズで効果を確認しながら進めました。
改善は4つのフェーズに分けて段階的に実施しました。第1フェーズでHero画像のWebP変換とpreload設定、第2フェーズで広告読み込みの遅延化と空間予約、第3フェーズでCritical CSSのインライン化とCSS分割、第4フェーズでJavaScriptバンドルの分割と不要なサードパーティスクリプトの除去を行い、各フェーズ完了後に効果を検証しました。
- Hero画像の最適化
- 広告読み込みの遅延
- Critical CSS inline化
- JavaScriptの分割読み込み
- CDN配信最適化
改善後の結果
約3ヶ月の改善プロジェクトにより全指標が「良好」基準を達成し、SEO順位とビジネス指標の両方で明確な改善が見られました。
全3指標がGoogleの「良好」基準を達成した結果、Search Consoleの「ウェブに関する主な指標」レポートでURL群の95%以上が「良好」に分類されるようになりました。オーガニック検索流入は改善前と比較して35%増加し、広告収益も広告viewability向上により12%増加するなど、パフォーマンス改善が直接的なビジネス成果につながりました。
- LCP: 2.1秒 (-66%)
- FID: 95ms (-66%)
- CLS: 0.08 (-77%)
- オーガニック流入+35%
- 直帰率45% (-20%)
改善プロセスのタイムライン
大規模サイトのCore Web Vitals改善は短期間で完了するものではなく、分析・実装・検証を繰り返す12週間のプロジェクトとして計画しました。各フェーズで効果測定を行いながら次の施策を調整するアジャイル型のアプローチにより、限られた開発リソースで最大限の効果を実現しています。
- Week 1-2: 現状分析、ボトルネック特定、改善計画策定
- Week 3-4: 画像最適化、Hero要素のpreload実装
- Week 5-6: JavaScript分割、Critical CSS実装
- Week 7-8: 広告最適化、レイアウト安定化
- Week 9-12: 効果測定、微調整、監視システム構築
事例2:Eコマースサイト
特有の課題
Eコマースサイトは商品画像の多さ、動的なフィルタリングUI、サードパーティの分析・広告スクリプトなど、Core Web Vitalsを悪化させる要因が多層的に存在します。
- 大量の商品画像
- 複雑なフィルタリング機能
- リアルタイム在庫更新
- A/Bテストツール
- レコメンデーション機能
創意工夫した解決策
商品一覧ページの表示速度と操作性を両立するため、仮想スクロールやService Workerを組み合わせた段階的な読み込み戦略を採用しました。
特に効果的だったのは仮想スクロールの導入で、画面に表示されている商品のみをDOMに描画し、スクロールに応じて動的に要素を生成・破棄することで、1000件以上の商品一覧でもスムーズな操作性を実現しました。Service Workerによる商品画像のプリキャッシュも組み合わせ、リピートユーザーのLCPを1秒以下に短縮することに成功しています。
- プログレッシブ画像読み込み
- 仮想スクロール実装
- Service Workerキャッシュ
- 非同期レコメンデーション
- パフォーマンス予算設定
ビジネスインパクト
コンバージョン率: 2.3% → 3.1% (+35%)
平均注文額: 変化なし
年間売上増加: +12%
事例3:BtoBサービスサイト
改善の重点分野
BtoBサービスサイトでは、リード獲得フォームこそがビジネス成果に直結する最重要コンバージョンポイントであるため、フォームページのCore Web Vitals改善が優先課題となります。
- フォーム読み込みの高速化(LCP)
- 入力時の応答性向上(FID)
- 入力中のレイアウト安定化(CLS)
具体的な改善策
BtoBサイトではリード獲得フォームが最も重要なコンバージョンポイントであるため、フォームの読み込み速度と入力時のレスポンス改善に集中しました。
フォームページのCritical Pathを分析した結果、バリデーションライブラリの同期読み込みがFIDを悪化させていることが判明しました。バリデーション処理を非同期に変更し、エラーメッセージ表示領域をCSSのmin-heightで事前確保することでCLSを改善、さらにフォーム入力に必要なJavaScriptのみをpreloadすることでLCPも短縮しました。
- Critical path の最適化
- Form validation の非同期化
- 入力フィールドのpreload
- エラーメッセージ領域の事前確保
測定結果
Core Web Vitals改善の効果はフォーム完了率に直結し、ページ表示速度と操作レスポンスの改善がリード獲得数の増加として明確に表れました。
改善後6週間の効果測定期間において、フォームページのLCPは3.8秒から1.9秒に短縮、FIDは210msから45msに改善、CLSは0.22から0.04に低下しました。これに伴いフォーム完了率が34%から41%へと7ポイント向上し、月間リード獲得数が約20%増加するという明確なビジネスインパクトを実現しました。
- フォーム完了率: 34% → 41%
- リード品質: 向上
- 営業チーム満足度: 向上
- ROI: +18%
10. まとめ
Core Web Vitals の要点
Core Web Vitalsは単なる技術指標ではなく、ユーザー体験の品質をGoogleが定量的に評価する仕組みであり、SEOとビジネス成果の両面に直接影響を与えます。
- LCP、FID、CLSの3指標でユーザー体験を総合評価
- SEOランキング要因として重要度が年々向上
- 技術的最適化とユーザー体験向上の両面で効果
- 継続的な監視と改善が成功の鍵
- ビジネス成果への直接的な貢献を実現
実践のためのアクションプラン
Core Web Vitalsの改善は一度にすべてを実施するのではなく、現状分析から始めて段階的に効果の大きい施策から順に取り組むことで、確実に成果を積み上げることができます。
- 現状のCore Web Vitals測定と問題特定
- 最もインパクトの大きい改善領域の優先順位付け
- 技術的改善の段階的実装
- 効果測定とA/Bテストによる検証
- 継続監視システムの構築
- チーム内でのKPIとして目標設定
- 定期的なレビューと改善サイクル確立
長期的な成功のポイント
一時的な改善で終わらせず持続的にパフォーマンスを維持するには、組織全体でデータに基づく意思決定プロセスと自動化された監視体制を構築することが不可欠です。
- データドリブンな意思決定
- パフォーマンス予算の設定と遵守
- 回帰防止のための自動テスト
- モバイルファーストの設計思想
- クロスファンクショナルチームでの取り組み
今後の展望
Core Web Vitalsは進化し続ける指標です。Googleは定期的に新しいメトリクスの追加や既存指標の調整を行っています。最新の動向を継続的にフォローし、変化に対応できる柔軟な最適化体制を構築することが重要です。
次に読む(関連コンテンツ)
タグから自動抽出した関連コンテンツです。
PSI/Lighthouseだけで迷子にならない。フィールドデータ→原因仮説→修正→再計測の型で、体感速度を改善する実務ガイド。
Googleが定めた、ユーザー体験を測る3つの指標。
画像/広告/埋め込み/フォントが主犯。事前にサイズを確保して動かさない。
原因は「メインスレッドが詰まっている」こと。重いJSとレンダリングが中心。
多くの場合は「画像・フォント・初期CSS/JS・サーバー応答」のどれか。まず主原因を特定する。
2025〜2026年のGoogleコアアップデート、公式ランキングシステム一覧、ランキング要因の重み付け、E-E-A-T最新動向、AI Overviewのゼロクリック影響、AI生成コンテンツ方針を網羅。公開情報ベースで最新のGoogle SEO基準を徹底解説。
高品質な店舗写真・商品写真の投稿からストリートビュー整備まで、ビジュアルコンテンツによるMEO強化戦略を解説。
競合が多い美容商材ECで、意図別の情報設計とCWV改善、構造化データ整備を同時に進めて伸ばしたケース。