LCPとは？画像を圧縮しても直らない理由と、4つの区間の見つけ方
「LCPが2.5秒を超えたから画像を圧縮した。でも数値が変わらない！」と困っていませんか？
画像を軽くするのが定番の対策とされているため、ほかに打つ手が見えにくいのも無理はありません。
この記事では、LCPを分ける4つの区間と、圧縮しても直らない理由、遅延読み込みの注意点を解説します。
表示速度の警告に手を焼いている方が、どこから直せばよいかを自分で判断できるようになります。
LCPとは、最も大きい要素が表示されるまでの時間
LCPは「Largest Contentful Paint」の略です。最初の画面の中で、最も大きい要素が表示されるまでの時間を測ります。
ページ全体の読み込みが終わるまでの時間ではありません。利用者が表示されたと感じる瞬間を数値にしたものです。Core Web Vitalsの3つの指標のひとつで、読み込みの速さを表します。
対象になる要素
LCPの対象になるのは、web.devで決められたいくつかの種類の要素だけです。主なものは次のとおりです。
- 画像のタグで置いた画像
- 動画のポスター画像
- CSSで指定した背景画像
- 文章を含むかたまり
この中で、最初の画面に占める面積が最も大きいものが1つ選ばれます。画像だと思い込んでいたら、見出しの文章が選ばれていたということもあります。
2.5秒以内が良好、4秒超は不良
基準は、2.5秒以内が良好です。4秒を超えると不良で、その間は改善が必要の区分になります。
| LCPの値 | 評価 |
|---|---|
| 2.5秒以内 | 良好 |
| 2.5秒を超え4秒以内 | 改善が必要 |
| 4秒超 | 不良 |
判定には、実際にページを開いた利用者の表示の75%が収まる値を使います。平均ではない点に注意してください。4人に3人が収まっていれば、その評価になるという考え方です。
PCとスマホで、別の要素が選ばれる
画面の大きさが違えば、最も大きい要素も変わります。PCでは写真、スマホでは見出しが選ばれることも珍しくありません。
PageSpeed Insightsは、モバイルとデスクトップを切り替えて診断できます。両方を見て、それぞれで何が選ばれているかを確かめてください。片方だけ直しても、もう片方は変わりません。
LCPを分ける4つの区間
LCPは1つの塊ではありません。隙間なく続く4つの区間の合計です。
どの区間が長いかで、打つ手はまったく変わります。web.devは、名前に遅延と付く2つの区間を、できるだけ0に近づけるよう勧めています。残りの2つには、それぞれ全体の約4割を充てる配分が目安です。まず、4つの区間がそれぞれ何を指すかを押さえてください。
① サーバーの応答
1つ目はTTFBで、ページを求めてからHTMLの最初の1バイトが届くまでの時間です。ここが終わらないと、ほかの区間は始まりません。
ここが長ければ、画像をどれだけ軽くしても全体は縮みません。原因はサーバーやリダイレクトの側にあるため、画像の作業は後回しです。TTFBの目安は800ミリ秒で、超えているならこちらを先に直してください。
② 読み込みを始めるまでの遅延
2つ目は、HTMLが届いてから、ブラウザが画像の取得を始めるまでの待ち時間です。ブラウザが画像の存在を知るのが遅いと、ここが長くなります。
HTMLの中に画像のタグがあれば、ブラウザは読みながら取得を始めます。JavaScriptで後から差し込む形では、その実行が終わるまで取得が始まりません。CSSの背景画像も、CSSを読み終えるまで見つかりません。
③ 読み込みにかかる時間
3つ目が、実際に画像を落としている時間です。圧縮や形式の変更が効くのは、この区間だけです。WebPのような軽い形式に変えるのも、この区間に効きます。
多くの記事が対策として挙げるのはここですが、4つのうちの1つにすぎません。とはいえ、写真を圧縮せずに載せているなら、まずはそこを直してください。言いたいのは、圧縮だけで足りるとは限らないということです。
④ 描画されるまでの遅延
4つ目は、画像を受け取っているのに画面に出せていない時間です。ブラウザがほかの処理で手一杯のときに長くなります。
読み込み直後に動くJavaScriptが多いページで、起きがちです。スライダーやアニメーション、解析のタグなどが当てはまります。この区間は、読み込みを速くしても縮みません。最初の画面に要らない処理は、表示が終わってから動かすように変えてください。
LCPは画像を圧縮しても直らないことがある
圧縮しても数値が変わらないのは、珍しいことではありません。実際の利用者のデータでも、画像を落とす時間は全体の一部にすぎないと分かっています。
手を付ける前に、どの区間が長いかを確かめるのが近道です。順番を逆にすると、作業しても数値が動かないまま時間だけが過ぎます。まずは実際のデータで、どの区間が長くなりがちかを見てください。
不良のサイトで長いのは、画像を落とす前
web.devは、Chromeで画像がLCPになったページの実測を区間ごとに公開しています。LCPが不良のサイトの中央値は次のとおりです。
| 区間 | LCPが不良のサイトの中央値 |
|---|---|
| サーバーの応答 | 2,270ms |
| 読み込みを始めるまで | 1,290ms |
| 読み込みにかかる時間 | 350ms |
| 描画されるまで | 360ms |
画像を落とす時間は、取得を始めるまでの待ち時間の4分の1ほどです。圧縮だけで2.5秒に収めるのは、この内訳では難しいと分かります。
縮めた分が、別の区間にずれる
web.devが例に挙げているのは、JavaScriptが終わるまで要素が隠されているページです。この作りでは、すべてが一度に表示されます。
画像の読み込みを速くしても、早く届いた分だけ描画を待つ時間が伸びます。合計が変わらないので、LCPも動きません。1つの区間だけを見て手を打つと、時間が隣に移るだけで終わることがあるのです。
開発者ツールで内訳を見る
内訳は、Chromeの開発者ツールで確かめられます。F12で開き、パフォーマンスのタブで記録してから、ページを読み込み直してください。
記録の中のLCPの項目を選ぶと、4つの区間の内訳が数値で出ます。CPUの速度を落とす設定を使えば、性能の低いスマホに近い状態で測れます。そのうえで、最も長い区間から手を付けてください。
LCP画像に遅延読み込みを付けてはいけない
遅延読み込みは、表示速度の対策としてよく紹介されます。ただし、LCPの画像に付けると逆効果です。
付けてよい画像と付けてはいけない画像を分けて考えてください。画面の外にある画像には有効で、外すべきは最初の画面の1枚だけです。この区別ができていないと、対策のつもりが悪化の原因になります。WordPressは標準で画像に遅延読み込みを付けるため、どの画像に付いているかの確認が欠かせません。
loading=”lazy”は、取得の開始を遅らせる
遅延読み込みは、画面の外の画像を後回しにする仕組みです。画面に入りそうになるまで、取得を始めません。
LCPの画像は最初の画面にあるので、これを付けると取得の開始が遅れます。4つの区間でいえば、2つ目の待ち時間が伸びる形です。ページのソースを開き、最上部の画像のタグに loading=”lazy” がないかを見てください。
背景画像は、CSSを読むまで見つからない
主役の画像をCSSの背景として置くと、ブラウザはCSSを読み終えるまでその画像に気づきません。取得の開始が、それだけ遅れます。
装飾のための背景ならCSSで構いませんが、最初の画面で大きく見せる写真は別です。画像のタグで書き直すと、HTMLを読む段階で取得が始まります。全面に敷いた写真がある作りなら、まずここを疑ってください。
fetchpriorityで優先度を上げる
反対に、LCPの画像には優先度を上げる指定を入れます。fetchpriority=”high”を付けると、ブラウザはほかの画像より先に取りに行きます。
WordPressは6.3から、LCPになりそうな画像にこの指定を自動で付ける仕様です。当サイトの記事でも、アイキャッチに付いていることを確かめました。テーマやプラグインが手を加えていると外れることもあるので、ページのソースで確認してください。
WordPressでLCPを確認する順序
WordPressの場合、手を入れる箇所は限られます。本文の画像より先に、テーマとアイキャッチを見てください。本文の画像は、WordPressが読み込みの指定を自動で整えているからです。
確認の順序を決めておくと、関係のない作業に時間を使わずに済みます。最初にやるのは、何がLCPに選ばれているかを確かめることです。そこが分かれば、見るべき区間も絞れます。
まずLCPの要素を特定する
PageSpeed Insightsの診断結果には、LCPに選ばれた要素が表示されます。最初にこれを見てください。
要素が文章なら、画像の作業はすべて無関係です。その場合は、Webフォントの読み込みや、その文章より前に動く重い処理を疑います。文章が選ばれているのに画像を圧縮しても、数値は動きません。要素が画像なら、アイキャッチの確認に進んでください。
記事ページでは、アイキャッチが選ばれやすい
記事ページでは、アイキャッチがLCPに選ばれやすくなります。本文より上にあり、面積も大きいためです。
この1枚に遅延読み込みが付いていないか、優先度の指定が入っているかを確かめてください。画像を最適化するプラグインが、区別せず一律に遅延読み込みを付けている例もあります。アイキャッチを出さない設定なら、最初の見出しが対象になりがちです。
直したあとは、同じ手順で測り直す
手を入れたら、同じ手順で測り直します。区間の内訳を見て、狙った区間が縮んだかを確かめてください。直す前の記録も残しておくと、比べやすくなります。
合計が変わっていなければ、縮んだ分が別の区間にずれています。実測値に反映されるまでには数週間かかるため、開発者ツールの記録で判断して構いません。数値が動くのを待ってから次に進む必要はありません。
LCPの改善に関するよくある質問
LCPを改善すると、検索順位は上がりますか
Googleは、Core Web Vitalsをランキングを決める際に考慮する要素の1つとしています。ただし、直しただけで大きく上がるとは限りません。
内容が検索の意図に合っていることが先で、LCPは待たせる時間を減らすために直すものです。最初の画面がなかなか出ないページは、読まれる前に閉じられやすくなります。順位より、読む人のために直すと考えてください。
モバイルとPCで数値が大きく違うのはなぜですか
回線と端末の性能が違ううえに、LCPに選ばれる要素そのものが違うことがあるためです。多くの場合、モバイルのほうが悪く出ます。
モバイルの参考値は、遅い回線と性能の低い端末を想定した測り方です。PCで良好でも、モバイルで不良になるのはこのためです。判断はモバイルの実測値を基準にしてください。Search Consoleでも、モバイルとPCは別々に表示されます。
LCPの要素が文章のときは、どうすればいいですか
文章が選ばれている場合、画像の取得は関係しません。疑うのは、サーバーの応答と、文章より前に動く処理です。
Webフォントの読み込みが終わるまで文字を隠す作りだと、描画が遅れます。端末に入っている書体を先に指定するか、読み込み中も代わりの書体で文字を出す指定にしてください。それだけで描画を待つ時間が縮むことがあります。
LCPの改善は、プラグインだけでできますか
画像の圧縮や形式の変更は、プラグインで補えます。画像の数が多いサイトでは、手作業より楽になるのは確かです。ただし、効くのは4つのうち3つ目の区間だけです。
サーバーの応答が遅い場合や、JavaScriptが描画を止めている場合には効きません。プラグインが一律に遅延読み込みを付け、かえって遅くなる例もあります。先に区間の内訳を見てから、道具を選んでください。
直してから、どれくらいで数値に反映されますか
実測値は直近28日間の集計なので、反映には数週間かかります。直した翌日に変わらなくても、失敗とは限りません。
その間は、PageSpeed Insightsの参考値と開発者ツールの記録で効果を確かめてください。Search Consoleで修正の確認を始めると、28日間のモニタリングに入ります。手元で縮んでいれば、あとは集計が追いつくのを待つだけです。
まとめ
LCPは、4つの区間の足し算です。画像の圧縮が効くのはそのうち1つだけで、不良のサイトほど画像を落とす前の時間が長くなっています。
最も長い区間を見つけてから手を付けないと、時間が別の区間にずれるだけで終わります。そして、LCPの画像には遅延読み込みを付けず、優先度を上げる指定を入れてください。
まずはPageSpeed Insightsで、LCPに選ばれている要素が何かを確かめてください。