LCPの改善とは？サーチコンソールでLCPの問題が出たら、PageSpeed InsightsでLCPの要素と4つの内訳を確かめる

Search Consoleの「ウェブに関する主な指標」を開いたら、モバイルの表にLCPが2.5秒(あるいは4秒)を超えているという行が出ていた。画像が重いのだろうと見当はついても、どの画像なのか、画像を軽くすれば消えるのか、急いで直すべきなのかまでは分からない。そこで手が止まっていないでしょうか。

この記事は、Search ConsoleでLCPの問題が出た個人ブロガーに向けて書いています。読み終えたときには、LCPが何の時間なのか、2.5秒と4秒が何の線なのか、自分の記事で遅いのがどこなのかをどの画面で探せばいいのかが分かるはずです。根拠にしたのは、Googleの開発者向けサイト web.dev の「Largest Contentful Paint（LCP）」と「Largest Contentful Paint を最適化する」、Search Consoleのヘルプ「Core Web Vitals レポート」、Googleの「PageSpeed Insights について」、Google 検索セントラルのページ エクスペリエンスの説明で、2026年10月14日に日本語版と英語版の原文で確かめました。web.dev の日本語版はAIによる翻訳と注記されているので、引用はどれも英語版と同じ意味かを見ています。「Largest Contentful Paint（LCP）」は、最終更新日が日本語版で2025年3月20日、英語版で2025年9月4日と版がずれていますが、引いた文は、あとで書く図の説明の1か所を除いて英語版と同じ意味でした。

私はこの記事のためにSearch ConsoleやPageSpeed Insightsの実際の画面を開いて確かめてはいません。画面や項目の名前は、上の説明ページに書かれている字で呼んでいます。また、LCPが何秒を超えている、という表の行の名前(問題名)の字は、今のSearch Consoleのヘルプには日本語版にも英語版にも見当たりませんでした。ヘルプにあるのは、低速・改善が必要・良好のステータスと、しきい値の表です。この記事では、行の名前は検索でよく使われる言い方として扱い、ヘルプの字としては引きません。レポートそのものの読み方、たとえば表に出たURLが似たページのグループの代表にすぎないことは、ウェブに関する主な指標レポートの見方は？URLグループとデータなしに書きました。

結論:LCPの要素を確かめ、4つの内訳のどこが長いかで疑う場所を決める

web.dev とSearch Consoleのヘルプに書かれていることと、そこから私が決めている進め方をまとめると、次の4つです。

• LCPは、画面に見えている中でいちばん大きな画像・文字のかたまり・動画が描かれるまでの時間。ブログなら、アイキャッチや1枚目の写真、あるいは記事のタイトルや最初の段落がそれに当たりやすい、と私は読んでいます
• 2.5秒以下が良好、4秒を超えると低速、その間が改善が必要。Search Consoleのヘルプは、「低速」から直すよう勧めています
• まずPageSpeed Insightsで、実際の訪問者のLCPと、LCPになっている要素を見る。上の欄が実際の訪問者のデータ、下の欄の「Largest Contentful Paint 要素」の診断に、要素と時間の内訳が出ます
• 内訳の4つのうち、どこが長いかで直す場所が変わる。画像を軽くして縮むのは「リソースの読み込み時間」の部分だけで、ほかの部分が長いと、画像を軽くしてもLCPがあまり縮まないことがあります

LCPとは:画面の中でいちばん大きいものが描かれるまでの時間

web.dev のLargest Contentful Paint（LCP）は、LCPをこう説明しています。

LCP は、ビューポート内に表示される最大の画像、テキスト ブロック、または動画のレンダリング時間を、ユーザーが最初にページに移動したタイミングと比較する形で確認できます。
— web.dev「Largest Contentful Paint（LCP）」

英語版は "LCP reports the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page." です。読者がリンクを押してページに移ってから、画面(ビューポート)に見えている範囲でいちばん大きなものが描かれるまでの時間、ということです。スクロールしないと見えない部分は、大きさに数えられません。

対象になる要素として、同じページは、<img> の画像、<svg> の中の画像、<video> の動画(ポスター画像か最初のフレーム)、CSSの url() で読み込んだ背景画像、文字を含む段落などのかたまり、を挙げています。画像だけではなく、文字のかたまりもLCPになる、という点を覚えておくと、あとで要素を確かめるときに迷いません。ブログでは、記事を開いてすぐ目に入るアイキャッチや1枚目の写真がLCPになりやすいことは、ブログの画像圧縮はSEOに効く？どこまでやるかは最初の1枚で決めるに書きました。

もう1つ、同じページには、Webフォント(サーバーから読み込む書体)を使った文字は、書体の読み込みを待って文字を隠している間は、描かれたものとして数えない、という趣旨の文があります(英語版の "Neither are text nodes using web fonts during the font block period." を私が訳したもの。日本語版はこの文の訳が崩れています)。文字がLCPになっているページでも、書体の読み込みが遅いとLCPが遅れることがある、ということです。

しきい値:2.5秒以下が良好、4秒を超えると低速

web.dev は、目標をこう書いています。

優れたユーザー エクスペリエンスを提供するには、サイトで Largest Contentful Paint を 2.5 秒以下に収めるようにします。
— web.dev「Largest Contentful Paint（LCP）」

英語版は "2.5 seconds or less"(2.5秒以下)です。同じページの図の説明は、日本語版では「良好な LCP 値は 2.5 秒未満、低い値は 4.0 秒を超え、その間の値は改善が必要です」となっていますが、英語版は "Good LCP values are 2.5 seconds or less, poor values are greater than 4.0 seconds, and anything in between needs improvement" で、良好の線は「未満」ではなく「以下」です。ちょうど2.5秒は良好に入る、と英語版の意味で読んでください。判定には、実際の訪問のうち75パーセンタイル、つまり4回に3回の訪問がその値か、それより速い値を使い、モバイルとパソコンを分けて見るよう勧めています。

Search Consoleのヘルプの表も、LCPは2.5秒以下が良好、4秒以下が改善が必要、4秒を超えると低速で、数字は同じです。この表に当てはめると、2.5秒を超えているという問題は「良好」に届いていないこと、4秒を超えているという問題は「低速」に当たることを示している、と私は読んでいます。ヘルプは、まず「低速」を直すよう勧め、「改善が必要」は改善の余地はあるが「低速」より重要度が下がる、と書いています。3つの指標を並べた表と、ステータスの決まり方はウェブに関する主な指標レポートの見方は？URLグループとデータなしにまとめました。

手順1:PageSpeed Insightsの上の欄で、実際の訪問者のLCPを見る

web.dev のLargest Contentful Paint を最適化するは、直す前に、LCPに問題があるか、どの程度かを実際の訪問者のデータで確かめるよう書いています。PageSpeed Insightsについては、上の欄を日本語版で「[実際のユーザーが体験していることを確認する]」、下の欄を「[パフォーマンスの問題を診断する]」と呼んだうえで、こう書いています(英語版は "Discover what your real users are experiencing" と "Diagnose performance issues" です。どちらも web.dev が書いている名前で、今の実際の画面の見出しの字は確かめていません)。

ウェブサイトの CrUX データが利用可能な場合は、常に実際のユーザーデータを優先的に確認してください。
— web.dev「Largest Contentful Paint を最適化する」

CrUXは、実際の訪問者のChromeから集めたデータのことです。Search Consoleで問題が出たのがモバイルなら、PageSpeed Insightsでもモバイルのほうを見てください。上下の欄がそれぞれ何を測っているかはPageSpeed Insightsの見方は？上の実際のユーザーのデータが先、下の点数はLighthouseの試験で毎回変わるに書きました。

注意したいのは、出てきた数字が記事1本のものとは限らないことです。同じページは「URL レベルで表示するのに十分なデータが URL にないが、オリジンにはデータがある場合、PageSpeed Insights では常にオリジンのデータが表示されます。」と書いています。オリジンは、ここではサイト全体のことです。サイト全体のLCPは記事ごとのLCPと大きく違うことがあり、ホームページは新しい訪問者がキャッシュの無い状態で開くことが多いため、サイトでいちばん遅いページになりやすい、ともあります。表示されているのが記事のデータか、サイト全体のデータかを先に確かめてください。

手順2:下の欄の「Largest Contentful Paint 要素」で、何がLCPかを見る

次に、LCPになっているのがどの要素かを確かめます。同じページは、下の欄(Lighthouse)について「LCP フィルタを使用して、LCP に関連する監査のみを表示します。」と書き、続けてこう説明しています。

Largest Contentful Paint 要素の診断では、LCP を構成するさまざまなタイミングの内訳がわかりやすく表示されます。
— web.dev「Largest Contentful Paint を最適化する」

英語版は "The Largest Contentful Paint element diagnostic shows a useful breakdown of the various timings that made up the LCP" です。ここで見るのは2つです。1つは、LCPの要素が画像か、文字(見出しや段落)か。もう1つは、次の章で書く4つの内訳のうち、どれが長いかです。要素が画像なら、記事のどの画像かも分かります。下の欄の項目の名前が、ここで引いた文や古い解説記事と違っていて分からないときはPageSpeed Insightsの「レンダリングをブロックしているリクエスト」とは？下の欄の項目は分析情報。直すかは上の欄で決めるに書きました。

ただ、下の欄はLighthouseが決まった端末と回線を模して1回読み込んだ試験の結果です。同じページは、Lighthouseの数字が上の欄の実際の訪問者のデータとおおむね合っているかを先に確かめ、合わないときは実際の訪問者のデータのほうが体験を正確に映している可能性が高い、と書いています。Chromeのデベロッパーツールの[パフォーマンス]パネルでも、手元で読み込んだときのLCPと内訳を見られる、とあります。パネルの開き方はINPの改善とは？サーチコンソールで「改善が必要」と出たら、PageSpeed InsightsとChromeで遅い操作を探すに書きました。

手順3:4つの内訳のうち、どこが長いかを見る

web.dev は、LCPの時間を4つの部分に分けて考えるよう勧めています。名前は日本語版で「Time to First Byte（TTFB）」「リソース読み込みの遅延」「リソースの読み込み時間」「要素のレンダリングの遅延」で、4つを足すとLCPの時間になります。この4つの紹介はページ表示速度はSEOに効くか、Core Web Vitalsより先に見る3つにも書きました。ここでは、それぞれが何の時間で、どのくらいが目安かを並べます。

LCPの要素が、Webフォントを使わない文字のように何も読み込まずに描けるものなら、2つ目と3つ目は0になります。目安の割合について、同じページはこう書いています。

4 つのサブパートのうち、2 つの名前には「delay」という単語が含まれています。これらの時間をできるだけゼロに近づけることが重要です。
— web.dev「Largest Contentful Paint を最適化する」

つまり、長くなりがちでも仕方がないのはサーバーの応答と読み込みの時間で、「遅延」の2つが長ければ、そこに縮める余地がある、という見方です。ただし、この割合は決まりではなく目安だとも書かれていて、2.5秒の目標から逆算して各部分の秒数に直すことは勧めていません。

そして、4つはつながっています。同じページは「ページの一部をその場しのぎで修正しただけで LCP に意義のある改善が見られることは稀です。」と書き、画像を圧縮して読み込み時間を縮めても、縮んだ時間が描画の遅延に移るだけでLCPが変わらなかった例を挙げています。その例の詳しい読み方はブログの画像圧縮はSEOに効く？どこまでやるかは最初の1枚で決めるに書きました。

ブログで重くなりやすい場所を、4つの内訳に当てはめる

web.dev の「Largest Contentful Paint を最適化する」が各部分の原因として挙げているもののうち、個人ブログで当てはまりやすいと私が考えるものを、内訳ごとに並べます。どれもコードの書き換えまでは書きません。設定がどこにあるかは、使っているブログサービスやテーマの説明で確かめてください。

読み込みの遅延が長い:最初に見える画像が、遅延読み込みになっている

画像の読み込みが始まるのが遅い場合、まず疑うのは遅延読み込み(画像が画面に近づくまで読み込まない仕組み)です。同じページには、はっきりした警告があります。

警告: LCP 画像を遅延読み込みしないでください。遅延読み込みすると、常に不要なリソース読み込みの遅延が発生し、LCP に悪影響を及ぼします。
— web.dev「Largest Contentful Paint を最適化する」

英語版は "Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and will have a negative impact on LCP." です。同じページは、HTMLで <img> に loading="lazy" を付けると読み込みの開始が遅れうる、と名指ししています。また、画像のアドレスを data-src などに隠しておき、スクリプトであとから入れる作りの遅延読み込みは、ブラウザがHTMLから画像を見つけられない例として挙がっています。同じページはさらに「ページで LCP 要素になる可能性が高いと思われる <img> 要素には、fetchpriority="high" を設定することをおすすめします。ただし、複数の画像に高い優先度を設定すると、LCP の削減に優先度設定が役立たなくなります。」とも書いています。優先するのは、LCPになる1枚だけです。アイキャッチの遅延読み込みを確かめる手順はブログの画像圧縮はSEOに効く？どこまでやるかは最初の1枚で決めるに書きました。

読み込み時間が長い:画像が大きい、Webフォントが重い

LCPの画像そのものの読み込みに時間がかかっているなら、ファイルを小さくする話になります。同じページは「ページの LCP リソース（存在する場合）は、画像またはウェブフォントのいずれかになります。」と書き、画像の寸法・新しい形式・圧縮と、Webフォントを小さくすることを挙げています。画像の寸法の決め方はブログの画像サイズは何px？本文は枠の幅から決め、アイキャッチはDiscover推奨の1200px・16:9が目安に書きました。

Webフォントについては、ファイルを小さくするほかに、書体の読み込みを待って文字を隠す必要があるかを考えるよう書かれています。CSSの font-display を auto と block 以外にすると、読み込み中も文字が表示され、LCPが書体の読み込みで止められなくなる、という説明です。テーマが書体を外から読み込んでいるかは、私の読みでは、LCPの要素が文字だったときに確かめる場所です。

ただ、この部分を先に疑いすぎないほうがいい、とも読めます。同じページの英語版は、LCPのうち読み込み時間の部分は、多くのサイトで大きなボトルネックにはなりにくいと書き、どの部分に力を入れるかは実際の訪問者のデータで決めるよう勧めています(私の訳。日本語版はここを「LCP の読み込み時間の大部分は」と訳していて、英語版の "the load duration portion of LCP" とずれています)。画像を軽くする前に、手順3の内訳で、読み込み時間が本当に長いかを見てください。

描画の遅延が長い:ページの先頭のスタイルシートやスクリプトが止めている

画像は読み込み終わっているのに描かれるまでが長いときは、ほかのものが描画を止めています。同じページは、主な理由の1つ目にこれを挙げています。

<head> のスタイルシートまたは同期スクリプトがまだ読み込まれているため、ページ全体のレンダリングがブロックされています。
— web.dev「Largest Contentful Paint を最適化する」

英語版は "Rendering of the entire page is blocked due to stylesheets or synchronous scripts in the <head> that are still loading." です。ほかに、画像は読み込み終わったのに、スクリプトの読み込みを待っていてLCPの要素がまだページに加えられていない場合、ほかのコードがLCPの要素を隠している場合、重いスクリプトの処理(長いタスク)でブラウザのメインスレッドがふさがっている場合も挙がっています。ブログでは、テーマやプラグインが読み込む大きなCSS、ページの先頭に貼ったタグがこれに当たりうる、と私は考えています。

なお、今回読んだ web.dev の2ページで「広告」という語が出てくるのは、次のTTFBの原因の例だけでした。広告のコードが描画を止めているかどうかは、私の読みでは、Lighthouseの診断やChromeの[パフォーマンス]パネルで、時間のかかっている処理がどこから来たものかを見て確かめる話です。広告は収益にかかわるので、LCPのためだけに一律に外すことは勧めません。

TTFBが長い:リダイレクトとサーバーの応答

サーバーが最初の応答を返すまでが長い場合について、同じページはこう書いています。

通常は高速なサイトで TTFB が遅くなる一般的な原因は、広告や短縮リンクなど、複数のリダイレクトを経由してユーザーがサイトにアクセスしていることです。
— web.dev「Largest Contentful Paint を最適化する」

英語版は "A common cause of a slow TTFB for an otherwise fast site is visitors arriving through multiple redirects, such as from advertisements or shortened links." です。記事のURLを変えたあとに古いURLから転送を何段も重ねていないか、SNSに貼るリンクが短縮URLを何度も経由していないかは、書き手にも確かめられます。一方で、サーバーそのものの速さについては、同じページが「この手順は、デベロッパーが最も制御できないことが多いため、最後に記載されています。」と書いているとおり、ブログサービスやレンタルサーバーの側の話になることが多い、と私は考えています。

順位にどこまで効くかは、レポートの記事と同じ結論

Googleは、検索セントラルのページ エクスペリエンスの説明で「Google のランキング システムでは Core Web Vitals が使用されます。」と書いています。同じページには、次の文もあります。

Search Console の Core Web Vitals レポートのようなレポートやサードパーティのツールで良い結果が得られても、Google 検索の検索結果で上位に表示されることが保証されるわけではありません。
— Google 検索セントラル「ページ エクスペリエンスが Google 検索の検索結果に与える影響について」

英語版は "...doesn't guarantee that your pages will rank at the top of Google Search results" です。この記事も、その両方を書いたウェブに関する主な指標レポートの見方は？URLグループとデータなしの結論を越えません。公式の文言の読み比べはページエクスペリエンスは順位に効く？公式がランキングで使うと名指ししている要素はCore Web Vitalsだけにあります。

直したあと、Search Consoleで[トラッキングを開始]を押すと、28日間のモニタリングが始まり、その間どのURLでも問題が出なければ解決したと判断されます。検証の仕組みも、上のレポートの記事に書きました。

よくある質問

LCPの要素が画像ではなく、見出しや段落でした

その場合、画像を軽くしてもLCPはあまり変わらないと考えられます。文字のLCPは、何も読み込まずに描けるなら内訳の2つ目と3つ目が0になるので、残るのはサーバーの応答と描画の遅延です。Webフォントを使っているなら、上で書いた書体の読み込みも疑う場所に入ります。

PageSpeed Insightsの上の欄に、記事のデータが出ません

記事1本の訪問が少ないと、URLのデータが足りずにサイト全体のデータが出たり、何も出なかったりします。PageSpeed Insightsの説明ページも、公開して間もないページや訪問の少ないページはデータが足りないことがある、と書いています。その場合は、下の欄の「Largest Contentful Paint 要素」の診断で、要素と内訳の見当をつけるところから始めます。

モバイルだけ問題が出て、パソコンは良好です

Search Consoleはモバイルとパソコンを別々に判定するので、珍しいことではありません。PageSpeed Insights についてによると、下の欄のLighthouseは、モバイルでは中くらいの性能の端末(Moto G4)とモバイル回線を模して測ります。PageSpeed Insightsでもモバイルに切り替えて、同じ手順で要素と内訳を見てください。

画像を圧縮したのに、LCPが変わりません

手順3のとおり、圧縮で縮むのは読み込み時間の部分だけです。読み込みが始まるまでの遅れや、描かれるまでの遅れが長いと、縮んだ時間がほかの部分に移るだけになることがあります。内訳をもう一度見て、長い部分から手を付けてください。

まとめ

• LCPは、画面に見えている中でいちばん大きな画像・文字のかたまり・動画が描かれるまでの時間。文字もLCPになる
• 2.5秒以下が良好、4秒を超えると低速、その間が改善が必要。web.dev の日本語版の図は「未満」だが、英語版は「以下」
• PageSpeed Insightsの上の欄で、実際の訪問者のLCPをモバイルとパソコンで確かめる。記事のデータが足りないと、サイト全体のデータが出る
• 下の欄の「Largest Contentful Paint 要素」の診断で、LCPの要素と時間の内訳を見る
• 4つの内訳のうち、名前に「遅延」が付く2つは0に近づけるもの。1枚目の画像の遅延読み込み、ページの先頭のスタイルシートやスクリプト、リダイレクトを、長い部分に合わせて疑う
• 順位については、Googleは Core Web Vitals を使うと書く一方、良い結果でも上位表示は保証されないとも書いている

LCPに手を入れるのは、内訳で長い部分が見つかってからで十分です。それまでの時間は、すでに検索結果に出ている記事のうち、どれの中身やタイトルを直すかを決めるほうに回せます。

LCPの問題が出たURLグループが複数あると、どのグループから手を付けるかも迷います。私は、検索結果にすでに出ていて、中身やタイトルを直す候補になっている記事を含むグループを先に見ています。ここから下は、私が作って売っているツールの宣伝です。

Search Consoleの「ページ」タブのエクスポートをZIPのまま置くと、掲載順位が4.0〜20.5位のページを拾い、表示回数100回以上は通常判定、30〜99回は参考判定、30回未満は本文中心の監査に分けます。並び順は、通常判定 → 参考判定 → 本文中心の監査の順。前2つの中は CTR機会差の多い順、30回未満は表示回数の多い順です。 判定と、そのうち1記事分の診断カードまでは無料です。有料は2,980円(税込)の買い切りで、無料の1件を除いた3記事分の診断カードが対象です。3記事分がそろうとき(判定に出た候補が4件以上のとき)だけご案内します。生成の利用期限は購入から7日間で、月額課金や自動更新はありません。ログインも不要です。 CSVファイルそのものはブラウザの外に出ませんが、診断カードを出すときは選んだ1ページ分の数値(URL・キーワード・順位・表示回数・CTR)を、タイトル取得を押したときは最大10件のURLを送ります。

⚠️ 判定に使うのは、Google検索のページごとの平均掲載順位・表示回数・CTRです(診断カードでは選んだ1ページの本文を読みます)。このツールは、表示速度もLCPもCore Web Vitalsも測りません。診断カードが本文を読むときも、文字と画像の代替テキストを読むだけで画像そのものは読み込まないので、LCPが遅いかどうかや、どの画像がLCPかは分かりません。LCPの確かめ方は、この記事の手順でPageSpeed Insightsを使って手で行ってください。判定に出た記事がSearch ConsoleのどのURLグループに入っているかを見比べるのも、手作業です。表示回数が0の行は読み込み時に除くので、検索結果に出ていない記事は候補に出てきません。並べ替えるだけで、順位やクリック数が上がることを約束するものではなく、掲載順位4.0〜20.5位に入るページが無いブログでは、候補が0件になることがあります。