LCP を解説：SEO のための最適化の方法

LCP は、重要なユーザー体験の指標であり、Google の順位要因です。ユーザーがページに移動するとき、ページ全体の読み込み時間は気にしません。気にするのは、メインのコンテンツがいつ見えて、読んだり操作したりし始められるかです。LCP はまさにその瞬間、つまり最も大きなコンテンツ要素が見えるようになる時点を測ります。LCP を正しく整えれば、ページは速く感じられます。誤れば、ほかの指標が良くても、ページは遅く感じられます。

LCP の最適化には、3 つの面からのアプローチが必要です。サーバーの応答時間（TTFB）の改善、レンダリングをブロックするリソースの排除、画像の最適化です。それぞれのアプローチが、LCP の異なるボトルネックに対処します。組み合わせれば、劇的な改善をもたらします。

LCP とは何か、どう測定されるか

Largest Contentful Paint（LCP）は、ページ上で見える最も大きなコンテンツ要素のレンダリング時間です。大きな画像、動画、見出し、テキストのブロックなどが該当します。LCP は、ユーザーがページに移動した時点から、その要素が見えるようになるまでを測ります。Google の LCP のドキュメントは、詳しい技術情報と最適化の戦略を提供しています。

LCP は、合格か不合格かの二値の指標ではなく、連続的なスコアです。Google は、LCP が 2.5 秒未満なら「良好」、2.5〜4 秒なら改善が必要、4 秒を超えると不良と定めています。ユーザーは、LCP が 2 秒未満のページを非常に速いと感じます。LCP が 3〜4 秒のページは、はっきり遅く感じられます。LCP が 5 秒を超えるページは、しばしば離脱されます。

LCP は、より大きなコンテンツ要素が現れるにつれて、ページの読み込み中に変わります。巨大な画像が 3 秒の時点で読み込まれれば、LCP は 1 秒から 3 秒に跳ね上がります。これは重要です。最初の描画時間だけを最適化すればよいのではありません。大きなコンテンツ要素がすべてすばやく読み込まれることを確かめなければなりません。

Time to First Byte（TTFB）を理解する

Time to First Byte（TTFB）は、ナビゲーションの開始から、サーバーが HTML 文書の最初のバイトを返すまでの時間です。TTFB は、LCP の下限を決めます。TTFB が 2 秒なら、ブラウザーはまだ HTML すら受け取っていないので、LCP は 2 秒より良くなりえません。TTFB を減らすことは、LCP を減らす前提条件です。

良好な TTFB は 600 ミリ秒未満です。600〜1,800 ミリ秒の TTFB は改善が必要で、1,800 ミリ秒を超えると不良です。TTFB が遅いなら、まずサーバーの最適化に集中しましょう。どれだけフロントエンドを最適化しても、遅いサーバーの埋め合わせにはなりません。

TTFB が遅くなる主な原因：非効率なバックエンドのコード、データベースのクエリ、サーバーの過負荷です。遅いホスティングも、高い TTFB の原因になります。共有ホスティングは、非常に遅いことがよくあります。より良いパフォーマンスのために、VPS かクラウドのホスティングにアップグレードしましょう。CDN を使って、ユーザーに近いサーバーからコンテンツを配信し、TTFB を減らします。

PageSpeed Insights は、「サーバーの応答時間」のセクションで TTFB を示します。TTFB がボトルネックなら、優先事項として強調されます。

最も大きなコンテンツ要素を特定する

LCP は、ページ上で最も大きなコンテンツ要素が何かによって決まります。ブログ記事では、最も大きい要素は大きなヒーロー画像かもしれません。商品ページでは、商品の写真かもしれません。ニュースサイトでは、記事の見出しかもしれません。LCP の要素を特定することが、最適化の第一歩です。

Chrome DevTools を使って、LCP の要素を特定しましょう。DevTools を開き、パフォーマンスタブに進み、記録を開始してページを再読み込みします。パフォーマンスの記録で、「Largest Contentful Paint」のマークを探します。その上にカーソルを重ねると、どの要素が LCP を引き起こしたかがわかります。要素がわかったら、それを最適化します。

LCP の要素は、画像であることが多くあります。画像は大きく、HTML が解析された後に読み込まれます。多くのサイトで、LCP に最も大きな影響を与えるのは、画像の読み込みの最適化です。ファーストビューより下の画像は遅延読み込みにでき、ファーストビューのコンテンツの LCP を速められます。

重要なリソースのプリロード

プリロードは、レンダリングに必要になる前に、リソースのダウンロードを早く始めるようブラウザーに伝えます。HTML の head の `` タグを使って、LCP の画像やそのほかの重要なリソースをプリロードしましょう。これは、ブラウザーに「このリソースをすぐにダウンロードし始めて」と伝えます。

例：``は、CSS が解析されるのを待たずに、ヒーロー画像のダウンロードをすぐに始めるようブラウザーに伝えます。リソースのサイズによって、LCP を 100〜500 ミリ秒減らせます。

プリロードには注意が必要です。プリロードしすぎると、帯域を無駄にします。最も重要なリソース（ヒーロー画像、重要なフォント、不可欠な CSS）だけをプリロードしましょう。Google の Core Web Vitals の最適化ガイドは、プリロードのベストプラクティスを説明しています。

LCP のための画像の最適化

LCP の要素が画像なら、画像のファイルサイズと読み込みの戦略を最適化しましょう。3 つの手法があります。

画像を圧縮する。TinyPNG、ImageOptim、Squoosh などのツールで、品質を損なわずに圧縮します。JPEG の圧縮は、ファイルサイズを 10〜40 倍減らせます。4G の回線では、画像のサイズが 100KB 増えるごとに、LCP が 100〜200 ミリ秒増えます。圧縮は ROI が高い手法です。

最新の形式を使う。WebP は JPEG より 25〜35% 小さく、AVIF はさらに小さくなります。HTML の `` 要素を使って、最新のブラウザーには WebP を、古いブラウザーには互換性のために JPEG を配信しましょう。形式の選択だけで、LCP を 200〜400 ミリ秒改善できます。

画像のサイズを指定する。width と height の属性を含めると、レイアウトのずれを防ぎ、ブラウザーが画像の読み込み前に領域を確保できます。これは LCP を直接改善しませんが、もう一つの Core Web Vitals の指標であるCumulative Layout Shift（CLS）を改善します。

レンダリングをブロックする CSS と JavaScript

レンダリングをブロックする CSS は、CSS がダウンロードされて解析されるまで、ブラウザーがページをレンダリングするのを妨げます。大きな CSS ファイルは、レンダリングを遅らせます。重要な CSS をインライン化し、残りを遅延させて、レンダリングをブロックする CSS を最小限にしましょう。

重要な CSSは、ファーストビューのコンテンツに必要な CSS です。この CSS を次の場所にインライン化します：`