一般的なページで、LCP要素とみなされるのは何ですか?

ビューポート内で最も多くのピクセルを描画する表示要素です。通常はヒーロー画像、大きな背景画像、あるいは大きな見出しテキストのブロックです。同じブロック内にまとめられたテキストノードは、この計測において1つの要素として扱われます。

LCPはモバイル、デスクトップ、それとも両方で計測されますか?

両方で計測され、しばしば結果が一致しません。ScanverraのWebsite Auditはデスクトッププロファイルと375pxのモバイルビューポートの両方で完全なLighthouseパスを実行します。ヒーロー画像をプリロードしているページであっても、その画像がモバイルに適したサイズで配信されていなければ、モバイルでは依然として遅くなり得るためです。

プリロードは常にLCPの改善に役立ちますか?

実際のLCPリソースに対してのみ効果があります。無関係なアセットをプリロードすると、同じ初期帯域幅を奪い合ってしまい、かえってLCPを悪化させることがあります。ファーストビュー内のすべてではなく、ブラウザが本来遅く発見してしまうであろう特定の画像やフォントだけをプリロードしてください。

CDNを導入したのに、なぜLCPが悪化したのですか?

CDNは、アセットが実際に訪問者の近くのエッジノードにキャッシュされて初めて効果を発揮します。デプロイやキャッシュパージ直後の最初のリクエストはコールドミスです。デプロイ直後にテストしている場合は、CDNが機能していないと結論づける前に、もう一度テストを実行し直してみてください。

最大コンテンツ描画時間(LCP)を改善する方法

LCPが遅くなる理由

LCPは、ブラウザがページをリクエストしてから、その最大の要素が描画を完了するまでの競争です。遅いLCPのほとんどは、この競争を妨げる次の4つの要因のいずれかに起因します。

遅いTime to First Byte。 サーバーが応答するだけで2秒かかる場合、LCPの計測はそれより早く始まることはなく、それ以降のすべての処理がその遅延を引き継ぎます。
最適化されていないヒーロー画像。 表示サイズに合わせて圧縮・リサイズされていない4MBのPNGは、私たちが最もよく目にする単一の原因です。
<head>内のレンダリングをブロックするCSSやJS。 レンダリングをブロックするリソースのダウンロードと解析が完了するまで、ブラウザはLCP要素を含め、何も描画できません。
リソースの発見が遅い。 LCPの画像がCSSのbackground-imageの奥深くでしか参照されていない、あるいはハイドレーション後にJavaScriptで読み込まれる場合、ブラウザはそのリソースの取得を本来より大幅に遅いタイミングまで開始できません。

LCP要素を特定する方法

どの要素がLCPであるかを推測するのは信頼できません。ビューポートのサイズやコンテンツによって変わるためです。Scanverraのウェブサイト監査は、デスクトッププロファイルと375pxのモバイルビューポートの両方で実際のLighthouseパスを実行し、その実行結果からLCPの値とタイミングを直接報告します。推定値ではないため、Googleのフィールドデータが最終的に反映するのと同じ指標そのものを見ていることになります。

Chrome DevToolsでは、Performanceパネルを開いてページ読み込みを記録し、タイミングトラック内の「LCP」マーカーを探すこともできます。それにホバーすると、レンダリングされたページ内の該当要素がハイライトされます。

修正方法

1. 実際のLCPリソースをプリロードする

ブラウザがCSSの解析やJSの実行を経てからでしかヒーロー画像を発見できない場合は、代わりにあらかじめその画像の存在を伝えてください。

ヒーロー画像をドキュメントのhead内でプリロードするtypescript

1export default function RootLayout() {
2  return (
3    <html lang="en">
4      <head>
5        <link
6          rel="preload"
7          as="image"
8          href="/hero.webp"
9          fetchPriority="high"
10        />
11      </head>
12      <body>{/* ... */}</body>
13    </html>
14  );
15}

2. LCP画像を高優先度としてマークする

コンポーネントレベルの画像タグを通じてヒーロー画像を描画している場合は、それを優先リソースとしてマークし、遅延読み込みされずに真っ先に帯域幅を確保できるようにしてください。

ヒーロー画像を優先読み込みにし、遅延読み込みをスキップするtypescript

1<img
2  src="/hero.webp"
3  alt="Product dashboard overview"
4  width={1200}
5  height={630}
6  fetchPriority="high"
7  loading="eager"
8/>

3. 画像自体を圧縮し、正しいサイズにする

ブラウザが対応している場合はPNG/JPEGの代わりにAVIFやWebPを配信し、実際に表示される最大サイズより大きな画像を配信しないようにしてください。3000px幅のソース画像をCSSで縮小表示しても、ダウンロードコストは元のサイズのままかかります。

4. まずTTFBを解消する

読み込みの遅い画像をプリロードしても、遅いサーバーそのものは解決しません。TTFBがLCPの予算のかなりの部分を占めている場合は、まずそちらを修正してください(下記のTTFBガイドを参照)。他のあらゆるLCP最適化は、ブラウザがそもそもどれだけ早く処理を開始できるかによって上限が決まってしまうためです。

5. クリティカルパスからレンダリングをブロックするリソースを取り除く

重要でないJavaScriptはdeferまたはasyncにし、ファーストビューに必要な少量のCSSはインライン化し、残りのスタイルシートは最初の描画をブロックしない形で読み込んでください。

ScanverraがLCPの問題をどう検出するか

Scanverraのパフォーマンスチェックは、稼働中のURLに対してデスクトップと375pxのモバイルビューポートの両方で本物のLighthouse監査を実行し、その実行結果から実際のLCPタイミングを他のCore Web Vitalsとあわせて報告します。これは合成された推定値でも、キャッシュされたサードパーティの数値でもありません。