Core Web Vitals 改善の実戦記録 — LCP を 3 秒から 1.2 秒まで短縮した方法

要点まとめ

• LCP (Largest Contentful Paint) は Google 検索順位に直接影響する中核指標です。
• 画像最適化、フォント読み込み戦略、コード分割を順番に適用し、LCP を 3.0 秒から 1.2 秒まで短縮しました。
• 画像と広告枠に明示的な寸法を指定し、レイアウトシフトを排除することで CLS を 0.28 から 0.04 まで改善しました。
• 実運用中の Next.js プロジェクトを題材にしていますが、同じ原則は React や Vue のプロジェクトにも適用できます。

はじめに — なぜ Core Web Vitals なのか

Google が 2021 年に Page Experience アップデートを展開して以降、Core Web Vitals は単なる UX 指標を超えて SEO のランキング要因へと組み込まれました。それ以降も Google はこれらのシグナルの比重を高め続けており、2024 年からは INP (Interaction to Next Paint) が FID に代わって正式な評価指標となっています。

私が運営する EC プロジェクトは、半年前まで PageSpeed Insights のモバイル評価で 38 点という散々なスコアでした。LCP は 3.0 秒、CLS は 0.28、INP は 320 ミリ秒 — 主要 3 指標がすべて「改善が必要」のレンジに入っていました。本稿では、この数字をどのように立て直したかを最初から最後まで記録します。

Core Web Vitals 3 つの指標をどう素早く理解するか

LCP — ページの「第一印象」となる速度

LCP は、ビューポート内で最も大きなコンテンツ要素 (通常はヒーロー画像や H1 テキスト) が描画されるまでの時間を測定します。Google が定めるしきい値は 2.5 秒以下 が Good、4.0 秒を超えると Poor に分類されます。

EC サイトでは、ヒーローバナー画像が圧倒的に LCP の候補になります。この 1 枚の画像が遅いと、他のあらゆる最適化が意味を失います。

CLS — レイアウトが「跳ねる」かどうか

CLS (Cumulative Layout Shift) は、ページ読み込み中に予期せず要素がずれる量を測定します。遅れて読み込まれる広告バナーや、寸法を指定していない画像が CLS を悪化させる代表的な原因です。0.1 以下 が Good のしきい値です。

INP — ユーザー入力にどれだけ素早く反応するか

INP は、クリック、タップ、キーボード入力などすべてのインタラクションに対する応答遅延を測定します。2024 年 3 月に FID から正式に置き換わり、200 ミリ秒以下 が Good の基準です。重い JavaScript バンドルがメインスレッドをブロックすると、INP は確実に悪化します。

問題の診断 — 初期計測

最適化の前に現状を正確に記録することが出発点です。次のツールを順番に使いました。

1. 1PageSpeed Insights — フィールドデータ (実ユーザーデータ) とラボデータ (Lighthouse) を同時に提供
2. 2Chrome DevTools の Performance タブ — レンダリングタイムラインと LCP 候補要素を確認
3. 3WebPageTest — CDN エッジサーバーから実環境計測し、フィルムストリップで視覚的に確認
4. 4Vercel Analytics / Sentry — 実ユーザーセッションから収集される Core Web Vitals

診断の結果、ボトルネックは 3 か所に絞り込まれました。

• ヒーロー画像 — 4.2MB の JPEG を最適化なしで タグで直接挿入
• Google Fonts — 3 つのフォントファミリーを @import で同期読み込み
• バンドルサイズ — 1.8MB のメインチャンクに、ツリーシェイクされていない複数のライブラリが同梱

LCP を 3.0 秒から 1.2 秒まで短縮した 3 つの方法とは

方法 1 — 画像最適化とプリロード

最も効果が大きかった対策です。ヒーロー画像の扱いを根本から見直しました。

Before

<img src="/banner.jpg" alt="メインバナー" />

After — Next.js Image コンポーネント + WebP 変換

import Image from 'next/image';

<Image
  src="/banner.webp"
  alt="メインバナー"
  width={1920}
  height={800}
  priority          // LCP 対象の画像には必ず priority を付ける
  quality={80}
  sizes="(max-width: 768px) 100vw, 1920px"
/>

priority プロパティを付けるだけで、Next.js は自動的に タグを挿入してくれます。WebP に変換した結果、ファイルサイズは 4.2MB から 340KB へ、およそ 92% 削減できました。

純粋な HTML/React プロジェクトの場合は、 に直接プリロードタグを追加します。

<link
  rel="preload"
  as="image"
  href="/banner.webp"
  type="image/webp"
/>

この 1 つの変更だけで、LCP は 3.0 秒から 1.8 秒まで短縮しました。

方法 2 — フォント読み込み戦略

Google Fonts を @import で読み込むと、ブラウザは CSS パースを中断してフォントリクエストを送信します。この待ち時間が LCP を大きく押し上げます。

Before

<style>
  @import url('https://fonts.googleapis.com/css2?family=Inter:wght@400;700&display=swap');
</style>

After — + display=swap + セルフホスティング

<link rel="preconnect" href="https://fonts.googleapis.com" />
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />


<link
  href="https://fonts.googleapis.com/css2?family=Inter:wght@400;700&display=swap"
  rel="stylesheet"
  media="print"
  onload="this.media='all'"
/>

media="print" で読み込んだ後 onload で media="all" に切り替えることで、レンダリングをブロックせずにフォント CSS を非同期取得できます。display=swap はウェブフォントの読み込み中もフォールバックフォントを即座に表示し、テキストが見え続ける状態を保ちます。

最大限のパフォーマンスを狙うなら、フォントをセルフホスティングして Google Fonts への往復通信を完全に排除します。

@font-face {
  font-family: 'Inter';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url('/fonts/inter-regular.woff2') format('woff2');
}

この段階で LCP は 1.8 秒から 1.4 秒まで短縮されました。

方法 3 — コード分割とバンドル最適化

1.8MB のメインチャンクは、ユーザーがページの操作可能状態に達する前に約 2MB の JavaScript をダウンロードして解析する必要があることを意味します。

実施した主な対策

1. 1動的インポート — 重いライブラリは必要なときだけ読み込む。

// Before: 常に読み込む
import Chart from 'chart.js';

// After: チャートコンポーネントが実際に描画されるときのみ読み込む
const Chart = dynamic(() => import('chart.js'), { ssr: false });

1. 1ツリーシェイクの監査 — import _ from 'lodash' を個別関数のインポートに置き換える。

// Before: lodash 全体を読み込む
import _ from 'lodash';

// After: debounce のみを読み込む
import debounce from 'lodash/debounce';

1. 1サードパーティスクリプトの遅延読み込み — 解析や チャットウィジェットなどはページがインタラクティブになった後に読み込む。

<script src="/analytics.js" defer></script>

バンドル最適化後、メインチャンクのサイズは 1.8MB から 620KB へ縮小し、LCP は 1.4 秒から 1.2 秒 まで短縮しました。

CLS を 0.28 から 0.04 まで改善した方法

CLS を悪化させていた最大の犯人は、広告と寸法指定のない画像でした。

広告枠: あらかじめ場所を確保する

/* 広告枠の最小高さを確保し、レイアウトシフトを発生させない */
.ad-container {
  min-height: 90px;  /* バナー広告 */
  min-width: 728px;
}

画像: 常に width / height を指定する

/* Before: 寸法なし → 読み込み中にレイアウトシフトが発生 */
<img src="/product.jpg" alt="商品" />

/* After: 寸法を明示 → ブラウザがあらかじめ場所を確保 */
<Image
  src="/product.jpg"
  alt="商品"
  width={400}
  height={300}
/>

動的コンテンツ: プレースホルダーを使う

// データ読み込み中はスケルトンを表示
{isLoading ? (
  <div className="h-48 bg-gray-200 animate-pulse rounded" />
) : (
  <ProductCard data={data} />
)}

この 3 つの変更で、CLS は 0.28 から 0.04 まで下がりました。

結果まとめ

自分のサイトの Core Web Vitals を確認するには

次のツールで現状のスコアを計測しましょう。

• PageSpeed チェッカー — PageSpeed Insights のスコアを即時確認
• メタタグチェッカー — SEO と OG タグの構成を同時に確認

よくある質問 (FAQ)

Q1. Core Web Vitals を改善すると検索順位は本当に上がりますか?

Core Web Vitals は Google が公式に認めるランキング要因の 1 つです。Google も Page Experience シグナルとして組み込まれていることを公表しています。ただしコンテンツ品質や被リンクなど他の要因の方が比重は大きいため、Core Web Vitals の改善は順位を保証する材料ではなく必要条件と捉えるべきです。

Q2. Core Web Vitals のどの指標が順位に最も影響しますか?

LCP は最もユーザーから見えやすく、直帰率に直結するため、間接的に順位への影響が大きい指標です。CLS も UX に直接影響するため優先度は高くなります。INP は新しい指標で、影響の大きさは今後さらに明確になっていく段階です。

Q3. 自分のサイトの LCP 要素はどう確認すればよいですか?

Chrome DevTools を開き、Performance タブでページ読み込みを記録し、タイムライン上の「LCP」マーカーを確認します。あるいは PageSpeed Insights を実行すれば、どの要素が LCP 候補かを直接教えてくれます。

Q4. Google Fonts は Core Web Vitals に悪影響を与えますか?

はい。@import で読み込むとレンダリングをブロックし、LCP 悪化の代表的な原因になります。 と display=swap の組み合わせ、もしくはフォントのセルフホスティングを強く推奨します。

Q5. Next.js は Core Web Vitals 改善にどれくらい役立ちますか?

かなり大きく役立ちます。Next.js は自動的な画像最適化 (WebP 変換、遅延読み込み、サイズ最適化)、組み込みのフォント最適化 (next/font)、ルートベースのコード分割を標準で提供します。これだけで、追加設定なしに Core Web Vitals が劇的に改善するケースも多くあります。

Q6. Core Web Vitals はどのくらいの頻度で確認すべきですか?

最低でも月 1 回のモニタリングを推奨します。PageSpeed Insights は過去 28 日間の実ユーザーデータを反映するため、変化が現れるまで時間がかかります。Google Search Console でフィールドデータの傾向を時系列で追う方が、単発の計測よりも実用的です。

ITEM 2 / 5