Core Web Vitals: LCPの最適化方法

Largest Contentful Paint(LCP)は、メインコンテンツの読み込み速度を測定します。これは、訪問者が最初に目にするヒーロー画像、見出し、または動画のことです。この読み込みに2.5秒以上かかると、ユーザーはサイトが遅いと感じ、直帰率が上昇し、Core Web Vitalsのスコアが悪化します。本ガイドでは、読み込みプロセスの4つのフェーズすべてにおいて、LCPの問題を診断し修正する方法を詳しく解説します。
重要なポイント
- LCPは、ユーザーのインタラクション前に表示される最大の可視コンテンツ要素のレンダリング時間を測定します
- Googleは、良好なCore Web Vitalsのために、ページ訪問の75%でLCPが2.5秒未満を達成することを要求しています
- 最適化には4つのフェーズが含まれます:TTFB、リソース発見、読み込み時間、レンダリング遅延
- ファーストビューのコンテンツに遅延読み込みを適用してはいけません—これは最も一般的なLCPの間違いです
Largest Contentful Paint(LCP)とは?
LCPは、ユーザーのインタラクション前にビューポート内で最大の可視コンテンツ要素のレンダリング時間を追跡します。これは<img>
、<video>
、またはテキストブロックの可能性があります。抽象的な指標とは異なり、LCPはユーザーが実際に体験すること—ページが「読み込まれた」と感じる瞬間を反映します。
Googleは明確な閾値を設定しています:
- 良好: 2.5秒未満
- 改善が必要: 2.5-4.0秒
- 不良: 4.0秒超過
Core Web Vitalsに合格するには、ページ訪問の75%が「良好」なLCPスコアを達成する必要があります。これはSEOランキングに直接影響します。GoogleがCore Web Vitalsをランキングシグナルとして使用しているためです。
LCP最適化の4つのフェーズ
LCPは単一の指標ではありません—4つの異なるフェーズの合計です。この内訳を理解することは、的確な最適化にとって重要です:
- Time to First Byte(TTFB): サーバー応答時間(総LCPの約40%)
- リソース読み込み遅延: TTFBからLCPリソースのダウンロード開始までの時間(10%未満)
- リソース読み込み時間: 実際のダウンロード時間(約40%)
- 要素レンダリング遅延: ダウンロード完了から視覚的レンダリングまでの時間(10%未満)
「遅延」フェーズはゼロに近づけるべきです。待機時間は純粋な無駄です。
フェーズ1: サーバー応答時間(TTFB)の最適化
遅いTTFBは他のすべてを台無しにします。サーバーが応答に3秒かかる場合、2.5秒のLCPを達成することは不可能になります。
一般的なTTFBの問題:
- 複数のリダイレクト(それぞれ100-500ミリ秒を追加)
- ユーザーから遠いサーバー
- 非効率なバックエンドコード
- データベースのボトルネック
解決策:
- サーバーサイドキャッシングの実装
- エッジロケーションからコンテンツを配信するCDNの使用
- リダイレクトの最小化—最終的なURL形式を直接使用
- データベースクエリとバックエンド処理の最適化
プロのヒント:CDNはサーバーの問題を隠すことがあります。URLパラメータ(例:?test=123
)でテストしてCDNキャッシュをバイパスし、真のサーバーパフォーマンスを明らかにしましょう。
フェーズ2: リソース発見遅延の排除
ブラウザはLCPリソースを即座に見つける必要があります。発見の遅延は時間の無駄です。
重要な間違い: LCP画像の遅延読み込み。ファーストビューのコンテンツにloading="lazy"
を使用してはいけません—これは意図的に最も重要な要素を遅延させます。
リソースを発見可能にする:
<!-- 良い例: HTML内の画像 -->
<img fetchpriority="high" src="/hero.webp" alt="...">
<!-- 悪い例: CSSに隠されている -->
.hero { background-image: url('/hero.webp'); }
CSS背景画像の場合(LCPには可能な限り避ける)、プリロードします:
<link rel="preload" fetchpriority="high" as="image" href="/hero.webp" type="image/webp">
fetchpriority="high"
属性は、ブラウザにこのリソースを他のものより優先するよう指示します。これがないと、画像はデフォルトで「低」優先度でダウンロードされることが多いです。
Discover how at OpenReplay.com.
フェーズ3: リソース読み込み時間の短縮
小さなファイルはより速くダウンロードされます。このフェーズは純粋な物理学です—バイトを減らせば、時間も減ります。
画像の最適化:
- 現代的な形式の使用(WebP、AVIF)
srcset
を使用したレスポンシブ画像の実装- 視覚的品質を損なわない圧縮
- 画像を正しくサイズ調整—モバイル用に4K画像を読み込まない
テキストLCPのフォント最適化:
font-display: swap
を使用してテキストを即座に表示- 必要な文字にフォントをサブセット化
- 重要なフォントのプリロード
CDNの考慮事項:
- 画像CDNは形式と圧縮を自動的に最適化
- 同一オリジン配信は接続オーバーヘッドを回避
- 利用可能な場合はCDNプロキシ機能を使用
フェーズ4: レンダリングブロッキングの最小化
リソースがダウンロードされても、メインスレッドの混雑によりレンダリングが停止する可能性があります。
一般的なブロッカー:
<head>
内のレンダリングブロッキングCSS- 同期JavaScript実行
- サードパーティスクリプトからの長いタスク
解決策:
重要なCSSのインライン化:
<style>
/* ファーストビューのスタイルのみ */
.hero { /* styles */ }
</style>
重要でないJavaScriptの遅延:
<script defer src="/app.js"></script>
WebフォントによってブロックされるテキストベースのLCP要素の場合、フォールバックレンダリングを確保:
@font-face {
font-family: 'Custom';
font-display: swap; /* フォールバックを即座に表示 */
src: url('/font.woff2') format('woff2');
}
特殊ケース: 動画と背景画像
動画要素: ポスター画像または最初のフレームがLCP候補になります。ポスター画像を他の画像と同様に最適化し、動画エンコーディングが効率的であることを確認してください。
CSS背景画像: これらは本質的な発見遅延を作成します。ブラウザは解析していないものをプリロードできません。重要な背景画像を<img>
要素に変換するか、明示的にプリロードしてください。
LCPの測定と監視
ラボデータ(PageSpeed Insights、Lighthouse)は問題の診断に役立ちますが、フィールドデータ(CrUX、RUM)は実際のユーザー体験を示します。常にフィールドデータを優先してください—これがGoogleがランキングに使用するものです。
Chrome DevToolsのPerformanceパネルを使用して、ローカルでLCPの内訳を確認できます。web-vitals JavaScriptライブラリはカスタム監視を可能にします:
import {onLCP} from 'web-vitals';
onLCP(({value, entries}) => {
console.log('LCP:', value, entries[0].element);
});
結論
LCPの最適化には、4つのフェーズすべてへの体系的な注意が必要です。TTFBから始めましょう—サーバーが遅い場合、どんな最適化も意味がありません。即座のリソース発見を確保し、ファイルサイズを最小化し、レンダリングブロッキングリソースを排除してください。最も重要なのは、LCP要素に遅延読み込みを適用しないことです。これらの最適化が実施されれば、2.5秒未満のLCPの達成は可能になるだけでなく、予測可能になります。
よくある質問
PageSpeed Insightsなどのラボツールは、特定のネットワーク速度とデバイスで制御された条件下でテストします。実際のユーザーは様々な接続、デバイス、地理的場所を持っています。CrUXからのフィールドデータは実際のユーザー体験を反映し、これがGoogleがランキングに使用するものです。
はい、JavaScriptフレームワークがクライアントサイドでコンテンツをレンダリングする場合、LCPを遅延させる可能性があります。ブラウザはコンテンツを表示する前に、JavaScriptをダウンロード、解析、実行する必要があります。サーバーサイドレンダリングまたは静的生成は、フレームワークベースのサイトのLCPを大幅に改善できます。
一般的にはい。ファーストビュー外の画像の遅延読み込みは、初期ページ重量を削減し、パフォーマンスを向上させます。ファーストビューのコンテンツ、特にLCP要素に遅延読み込みを適用しないことを確認してください。初期ビューポート外の画像にはloading=lazyを使用してください。
サードパーティスクリプトはメインスレッドをブロックし、リソースの読み込みとレンダリングの両方を遅延させる可能性があります。また、レンダリングブロッキングリソースを注入する場合もあります。サードパーティスクリプトを非同期で読み込み、重要でないものは遅延させ、重い処理タスクにはWeb Workerの使用を検討してください。
Gain control over your UX
See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.