LCPとは？画像を圧縮しても直らない理由と、4つの区間の見つけ方

LCPとは、最も大きい要素が表示されるまでの時間

LCPは Largest Contentful Paint の略です。画面の中で最も大きい要素が表示されるまでの時間を測ります。

ページ全体の読み込みが終わるまでではありません。利用者が「表示された」と感じる瞬間を数値にしたものです。

ページ全体ではなく、画面内で最も大きい1つ

対象になるのは、画像、動画のポスター画像、背景画像、そして文章のかたまりです。この中で、最初に表示される画面の中で最も面積の大きいものが1つ選ばれます。

注意が必要なのは、PCとスマートフォンで別の要素が選ばれることがある点です。画面の大きさが違えば、最も大きい要素も変わります。

PageSpeed Insightsは、モバイルとデスクトップを切り替えて診断できます。両方を見て、それぞれのLCP要素を確認します。片方だけ直しても、もう片方は変わりません。

2.5秒以内が良好、4秒超は改善が必要

基準は2.5秒以内が良好、4秒を超えると改善が必要です。この判定は、実際にページを開いた利用者のうち75%がその値に収まっているかで決まります。

この75%という基準は、平均ではありません。4人に3人が2.5秒以内なら合格、という考え方です。通信の遅い回線や性能の低い端末の利用者が多いサイトでは、同じ作りでも数値が悪く出ます。

Core Web Vitalsの3指標のひとつなので、TTFBと違って基準を満たす意味があります。

• 参考：Largest Contentful Paint (LCP)
• 関連記事：Core Web Vitalsとは？3指標の意味と、直さなくていい場合の見分け方

LCPは4つの区間に分かれている

LCPは1つの塊ではありません。隙間なく続く4つの区間の合計です。どの区間が長いかで、打つ手がまったく変わります。

サーバーの応答（TTFB）

1つ目はTTFBです。ブラウザがリクエストを送ってから、最初の1バイトが届くまでの時間です。

ここが長ければ、画像をどれだけ軽くしても始まりません。サーバー側の問題なので、画像の作業は後回しになります。

目安は、TTFB単体で800ミリ秒を超えているかどうかです。超えているなら、LCPの目標である2.5秒のうち3分の1をここで使っています。まずTTFB側の対処が先になります。

読み込みを始めるまでの遅延

2つ目は、HTMLが届いてから、ブラウザが画像の取得を始めるまでの待ち時間です。

この区間が最も長くなりがちです。Googleの調査では、LCPが不良のサイトは、画像を落とす時間より落とし始めるまでの待ち時間のほうが約4倍長いという結果が出ています。中央値で1.3秒です。

この区間が長い理由は、ブラウザが画像の存在を知るのが遅いためです。HTMLの中に画像のタグが書かれていれば、ブラウザは読みながら並行して取得を始めます。JavaScriptで後から差し込む形では、そのJavaScriptを実行し終えるまで始まりません。

読み込みにかかる時間

3つ目が、実際に画像を落としている時間です。圧縮や形式の変更が効くのはここだけです。

多くの記事が改善策として挙げるのはこの区間ですが、4つのうちの1つでしかありません。

それでも、この区間を軽視してよいわけではありません。写真を圧縮せずに載せているなら、まずそこを直します。ここで言いたいのは、圧縮だけで足りると考えないほうがよい、ということです。

描画されるまでの遅延

4つ目は、画像を持っているのに画面に出せていない時間です。JavaScriptの処理が終わるまで要素が隠されている構成で長くなります。

ネットワークの問題ではなく、ブラウザが他の作業で手一杯という状態です。画像はすでに手元にあるのに、描く順番が回ってきません。この区間は、読み込みを速くしても縮みません。

この区間が長いサイトは、読み込み直後に多くのJavaScriptを動かしています。スライダー、アニメーション、解析タグなどです。画像は届いているのに、描く順番が回ってきません。

対処は、それらの処理を後回しにすることです。最初の画面に必要のないものは、表示が終わってから動かします。

• 参考：Optimize Largest Contentful Paint
• 関連記事：TTFBとは？800msと600msは何が違うのか、直す前に見ること

LCPは画像を圧縮しても直らないことがある

ここが本題です。圧縮しても数値が変わらないことは、珍しくありません。

縮めた分が別の区間にずれる

web.devが例として挙げているのは、JavaScriptが終わるまで要素が隠されているページです。

この構成では、画像の読み込みを速くしても、早く届いた分だけ描画待ちの時間が伸びます。合計が変わらないので、LCPも動きません。

最も長い区間から手を付ける

だから、まず4区間の内訳を見ます。Chromeの開発者ツールで、LCPの内訳を区間ごとに確認できます。

そのうえで、最も長い区間に手を付けます。順序を逆にすると、作業しても数値が動きません。

内訳の確認は開発者ツールで行います。F12で開き、パフォーマンスのタブで記録を開始し、ページを読み込んでから停止します。記録の中にLCPの項目が表示され、選ぶと4つの区間の内訳が数値で出ます。

CPUの速度を落とす設定を併用すると、性能の低い端末に近い状態で測れます。実際の利用者の環境に近づけたい場合は、この設定を使います。

待ち時間はダウンロード時間の約4倍

実際に多いのは、2つ目の区間です。画像そのものは軽いのに、ブラウザがその存在を知るのが遅い。

HTMLの中に画像のタグが書かれていない構成、たとえばJavaScriptで後から差し込む形や、CSSの背景画像として指定している形で起きます。CSSを読み終えるまで、ブラウザはその画像の存在を知りません。

対処は2つあります。ひとつは、その画像をHTMLの画像タグとして書き直すこと。もうひとつは、HTMLの先頭で先に読み込むよう指示を入れることです。前者のほうが確実ですが、デザインの都合で難しい場合は後者を使います。

LCP画像に遅延読み込みを付けてはいけない

ここは誤った説明が多い箇所です。結論から書くと、遅延読み込みはLCPの改善策ではありません。

loading=”lazy” は開始を遅らせる

遅延読み込みは、画面外の画像を後回しにする仕組みです。表示領域に入るまで読み込みません。

LCP要素は最初の画面にあるので、これを付けると読み込みの開始が遅れます。後回しにされる分だけ、改善どころか悪化します。

画面外の画像に付けるのは有効です。付けてはいけないのはLCP要素の1枚だけという理解が正確です。

確認は、ページのソースを開いて行います。アイキャッチや最上部の画像のタグを探し、loading=”lazy” が入っていないかを見ます。入っていれば、その1枚だけ外します。

背景画像もCSSを読むまで見つからない

CSSの背景画像としてメインの視覚要素を置くと、ブラウザはCSSを落として解釈するまで、その画像に気づきません。

最も目立たせたい画像は、HTMLに画像のタグとして書きます。装飾のための背景ならCSSで構いませんが、主役の1枚は別です。デザイン上の都合で背景にしている場合は、見直す価値があります。

判断の基準は、その画像が最初の画面に大きく映るかどうかです。背景として全面に敷いている写真は、まず対象になります。

fetchpriority で優先度を上げる

逆に、LCP要素には優先度を上げる指定を入れます。fetchpriority="high" を付けると、ブラウザは他のリソースより先に取りにいきます。

当サイトも、記事のアイキャッチにこの指定を入れています。テーマ側で、最初の1枚だけに自動で付ける処理を書いています。

あわせて、その画像から遅延読み込みを外す処理も入れています。WordPressは標準で、本文の画像に遅延読み込みを自動で付けます。最初の1枚だけは対象から外す必要があります。

• 参考：Common misconceptions about how to optimize LCP

WordPressでLCPを確認する順序

WordPressの場合、手を入れる箇所は限られます。本文の画像より、テーマ側とアイキャッチを先に見ます。

まずLCP要素が何かを特定する

PageSpeed Insightsの診断結果に、LCP要素として選ばれた要素が表示されます。まずこれを見ます。

画像だと思っていたら見出しの文章だった、ということがあります。要素が文章なら、画像の作業はすべて無関係です。

文章がLCP要素になっている場合、原因はWebフォントの読み込みか、その文章より前に重い処理があることです。画像を圧縮しても数値は動きません。

アイキャッチが対象になることが多い

記事ページでは、アイキャッチがLCP要素になりやすい。本文より上にあり、面積も大きいためです。

ただし、アイキャッチを表示しない設定にしている場合は、最初の見出しか本文の1段落目が対象になります。その場合は、フォントの読み込みを見直します。

この1枚に遅延読み込みが付いていないか確認します。画像を最適化するプラグインが、区別せず一律に付けている場合があります。ページのソースを開き、アイキャッチのタグに loading=”lazy” が入っていないかを見ます。

テーマ側の画像に指定を入れる

本文の画像には、WordPressが自動で寸法を書き込みます。一方、テーマのファイルに直接書いた画像は自分で指定します。

トップページのメイン画像、ヘッダーのロゴが該当します。当サイトはプラグインを使っていないため、この作業を代わりにやってくれる仕組みがありません。すべて手作業で入れています。

手作業と書くと大変に聞こえますが、対象は数枚です。ヘッダーのロゴ、トップページの主要な画像、アイコン類。一度入れれば、その後は触りません。

直したあとの確認

手を入れたら、同じ手順で測り直します。区間の内訳を見て、狙った区間が縮んでいるかを確認します。合計が変わっていなければ、縮んだ分が別の区間にずれています。

実測値に反映されるまでは数週間かかります。反映を待たず、参考値と開発者ツールで判断して構いません。数値が動くのを待ってから次に進む必要はありません。

• 関連記事：WordPressで作るメリット｜プラグインを入れないという選択肢

まとめ

LCPは4つの区間の足し算です。画像の圧縮が効くのは、そのうち1区間だけ。最も長い区間を見つけてから手を付けないと、時間が別の区間にずれるだけで終わります。

そして、LCP要素に遅延読み込みを付けてはいけません。改善策として紹介されていることがありますが、逆効果です。

まずPageSpeed InsightsでLCP要素が何かを確かめ、それが画像なら遅延読み込みが付いていないかを見るところから始まります。