WebサイトのCore Web Vitals（LCP・INP・CLS）を改善しPageSpeed Insightsで高スコアを維持する実践手法
Webサイトのユーザー体験（UX）と検索エンジン評価（SEO）を測るうえで欠かせない指標が Core Web Vitals（コア ウェブ バイタル） です。ページの表示速度が遅い、あるいは読み込み中にレイアウトがガタつくと、ユーザーの直帰率が跳ね上がるだけでなく、Google Search Console の「ウェブに関する主な指標」でも改善が必要と判定されます。
本記事では、現在 Core Web Vitals を構成する3つの重要指標 LCP・INP・CLS の基準値と、技術ブログやコーポレートサイトで実際に効果があった具体的なボトルネック解消手順を解説します。
1. Core Web Vitals の3指標と「良好（Good）」の基準値
まずは Google が定義している3つの指標の役割と、モバイル・デスクトップ双方でクリアすべき目標値を確認しましょう。
| 指標名 | 略称 | 計測する対象 | 良好 (Good) | 改善が必要 | 不良 (Poor) |
|---|---|---|---|---|---|
| Largest Contentful Paint | LCP | ファーストビュー内で最も面積の大きい要素（見出し・メイン画像）が表示されるまでの時間 | 2.5秒以下 | 2.5秒超〜4.0秒以下 | 4.0秒超 |
| Interaction to Next Paint | INP | ユーザーのクリック・タップ・キー入力から次の画面描画が完了するまでの応答時間（旧FIDの後継） | 200ミリ秒以下 | 200ms超〜500ms以下 | 500ms超 |
| Cumulative Layout Shift | CLS | ページ読み込み中〜閲覧中に発生した「意図しないレイアウトのズレ」の累積スコア | 0.1以下 | 0.1超〜0.25以下 | 0.25超 |
これら3指標は、テスト環境のシミュレーション値（Lighthouse のラボデータ）だけでなく、実際のChromeユーザーの計測データ（CrUX：フィールドデータ）の 75パーセンタイル値（上位75%のユーザーが基準値を満たしているか）で評価されます。
2. LCP（最大視覚コンテンツの表示時間）を2.5秒以下に短縮する手順
LCP が悪化する原因は、大きく 「1. サーバー応答（TTFB）の遅れ」「2. レンダリングブロックリソース（CSS/JS）」「3. Webフォントやメイン画像の読み込み遅延」 の3つに分解できます。
2.1 日本語Webフォント（Google Fonts等）による遅延を解消する
日本のWebサイトで LCP を悪化させる最大の原因のひとつが、数メガバイトにおよぶ日本語 Web フォント（Noto Sans JP 等）のダウンロード待ちです。
特別なブランディング要件がない限り、OS標準搭載の高品位なシステムフォント（macOS/iOS ならヒラギノ角ゴ、Windows なら BIZ UDPGothic やメイリオ）を直接指定することで、フォント通信量 0KB・待ち時間 0ms で美しい日本語表示を実現できます。
/* 通信待ちゼロで可読性を最大化する日本語システムフォントスタック */
html {
font-family:
"Hiragino Kaku Gothic ProN",
"Hiragino Sans",
"BIZ UDPGothic",
"Meiryo",
-apple-system,
BlinkMacSystemFont,
"Segoe UI",
Roboto,
sans-serif;
}どうしても Google Fonts を使用する場合は、font-display: swap; を指定し、テキストが白紙になる現象（FOIT: Flash of Invisible Text）を防ぐことが必須です。
2.2 ファーストビュー画像には loading="lazy" を付けない
画像の遅延読み込み（loading="lazy"）は画面外の画像には有効ですが、記事タイトル直下のアイキャッチ画像（LCP要素）に loading="lazy" を付与すると、ブラウザのプリロードスキャナが画像の取得を後回しにしてしまい、LCP が大幅に悪化します。
ファーストビューに入るメイン画像には、逆に fetchpriority="high" と decoding="async" を指定します。
<!-- ファーストビュー（LCP対象）の画像 -->
<img
src="/images/hero-diagram.webp"
alt="システム構成図"
width="1200"
height="630"
fetchpriority="high"
decoding="async"
/>
<!-- スクロールしないと見えない記事中盤以降の画像 -->
<img
src="/images/step2-screenshot.webp"
alt="設定画面のスクリーンショット"
width="800"
height="450"
loading="lazy"
decoding="async"
/>3. CLS（累積レイアウトシフト）を「0.00」に抑え込む設計
「記事を読もうとしてリンクをタップした瞬間に、上の画像や広告枠が遅れて読み込まれ、別の場所を誤タップしてしまった」という現象を防ぐのが CLS 対策です。
3.1 すべての画像・SVG・iframe に width と height を明記する
CSS で max-width: 100%; height: auto; を指定している場合でも、HTML の <img> タグ自体に width と height 属性が書かれていれば、モダンブラウザは画像ファイルがダウンロードされる前にアスペクト比（縦横比）を計算し、あらかじめ正確な高さの空白領域を確保してくれます。
3.2 動的コンポーネントや広告枠には min-height で領域を予約する
後から JavaScript で挿入される要素（目次ウィジェット、SNS埋め込み、広告ユニットなど）がある場合、コンテナ要素に CSS で最小高さを指定しておくことで、後続の本文が下に押し下げられるレイアウトシフトを防げます。
.ad-slot-container {
min-height: 280px;
display: flex;
align-items: center;
justify-content: center;
background-color: #f8fafc;
}4. INP（次の描画までのインタラクション時間）を改善するメインスレッド最適化
2024年3月に FID（初回入力遅延）に代わって正式指標となった INP は、ページ滞在中のすべてのクリック・タップ・キー操作に対する応答性を測定します。
4.1 不要なクライアントサイド JavaScript を送らない
React や Vue で構築されたサイトで、単なる静的な記事本文までクライアント側で Hydration（水和処理）していると、スマートフォン端末の CPU メインスレッドが数百ミリ秒にわたってブロック（Long Task 化）されます。
Astro のようにデフォルトで JavaScript を出力しない構成を採用し、インタラクティブなUI（検索モーダルやフォーム送信処理など）だけを軽量な Vanilla JS または部分的な Island として実装することで、INP はほぼ確実に 50ms以下（基準値200msに対して余裕で合格） に収まります。
4.2 サードパーティスクリプト（解析タグ等）の読み込み制御
アクセス解析や広告タグを導入する際は、<script async> または <script defer> を徹底し、HTML パーサーをブロックしないように配置します。
5. デプロイ前のローカル計測ワークフロー
本番環境に公開する前に、Chrome DevTools の Performance パネル と Lighthouse を使って以下の手順で検証する習慣をつけると、スコア低下を未然に防げます。
- シークレットウィンドウ（Chrome拡張機能の影響を排除するため）を開く。
- DevTools を開き、Lighthouse タブで 「モード：ナビゲーション」「デバイス：モバイル」 を選択して解析を実行する。
- 「診断（Diagnostics）」 セクションで「レンダリングを妨げるリソースの除外」や「レイアウトシフトの大きな要素」が指摘されていないか確認する。
まとめ
Core Web Vitals の改善は、複雑なチューニングを行う前に 「1. 重いWebフォントを避ける」「2. 画像の縦横サイズと遅延属性を正しく使い分ける」「3. 余分なJavaScriptバンドルを配信しない」 という基本の3原則を守るだけで、PageSpeed Insights のモバイル・デスクトップともに 95〜100 点の水準を安定して維持できるようになります。