Largest Contentful Paint画像の最適化

ステップバイステップのLCP画像最適化ガイド

Arjen Karel - linkedin

Last update: 2026-07-10

Largest Contentful Paintの画像を最適化する

このガイドは、Largest Contentful Paint (LCP)ハブの一部です。ほとんどのウェブサイトでは、LCP要素は画像です。画像の扱いを誤ると、LCPスコアが低下します。本記事では、画像を高速化するためのあらゆるテクニックを解説します。

Googleによると、インターネット上の全ページビュー（デスクトップとモバイルの両方を含む）のうち、Largest Contentful Paintスコアが「良好」なのはわずか65%にすぎません。つまり、35%のページビューが基準を満たしておらず、その原因の一部は画像に関するミスにあります。本記事では、画像がLargest Contentful Paint要素になる場合の、一般的なグッドプラクティスのパターンとよくあるミスを解説します。

LCPのヒント：画像の最適化だけでなく、Largest Contentful Paintのあらゆる詳細をマスターしたい場合は、Largest Contentful Paintのセクションを参照してください。4つの主要なコンポーネントを最適化する方法を解説しています：

Time to First Byte：ブラウザがHTMLを待つ時間です。この時間の大部分は通常サーバーの応答待ちですが、リダイレクト、接続時間、暗号化なども含まれます。
Load Delay：LCP要素の読み込みを開始できたはずの時点から、実際に読み込みが開始されるまでの時間差です。詳細は、Resource Load Delayの完全ガイドを参照してください。
Resource Load Time：LCPリソースの読み込みにかかる時間です。圧縮やミニファイを最適化することで、この時間を短縮できます。詳細は、Resource Load Durationの完全ガイドを参照してください。
Render Delay：リソースが最適化されていても、ブラウザが他のタスク（通常はスタイルシートのダウンロードや重いJavaScript処理）でビジー状態になり、LCPのレンダリングが遅れることがあります。詳細は、Element Render Delayの完全ガイドを参照してください。

これらすべての要因が重要ですが、LCP要素が画像である場合（実際そうであることが非常に多いです）、できるだけ早く読み込ませるための簡単な手順があります！

Largest Contentful Paintの実験

私は常にこう言っています。人の話を聞いて学ぶことは大切ですが、それを鵜呑みにしてはいけません。世の中には誤った情報を広める「専門家」が多すぎます。そのため、LCP要素が最適に読み込まれないとどうなるかを実際に確認できる、全自動のLCP実験環境を作成しました。 githubのLCP Testを確認するか、ライブデモを試してみてください！

複数のLCPシナリオを自動的にテストし、結果を表示します。以下では、これらのシナリオについて説明し、LCP画像要素の読み込みが高速化または低速化する仕組みとその理由を解説します。

1. LCP候補をコントロールする：テキスト優先戦略

画像によるLargest Contentful Paintを改善する最も簡単な方法は何でしょうか？画像を使わないことです。え？と思われるかもしれませんが、その通りです。解説しましょう。

テキストが画像より速い理由。パフォーマンスの差は、リクエストのパイプラインに起因します。テキストノード（<h1>や<p>など）はメインのHTMLドキュメントの一部です。個別のリソースリクエストは発生せず、そのレンダリングはCSSによってのみブロックされます。一方、画像は外部リソースであり、独自のHTTPリクエストが必要です。これにより、CSSによるブロックに加えて、ネットワーク遅延（DNS、TCP、TLS、およびダウンロード時間）が発生します。この違いがパフォーマンスの差を生む根本的な原因であり、LCP候補のコントロールが強力かつ専門的な戦略である理由です。

では、画像とテキストの使い分けはどうすべきでしょうか？画像は重要であり、サイトを視覚的に魅力的なものにします。しかし、Core Web Vitalsはどの要素がLCPになるかを気にしません。LCP要素がテキストベースの要素である場合、通常はFirst Contentful Paintと同時に発生します。

So should you switch to a text-based Largest Contentful Paint element? That depends! Images matter and they make your site visually appealing. That means you will not hear me advocate for switching to old boring text elements. But mistakes also happen! I wish I had a dollar for every category page that fell victim to the "Accidental LCP" anti-pattern. This is where a page "forgets" to add a descriptive category text above the fold, causing a lazy-loaded product image to become the LCP and delaying load times by seconds. This often happens when designers place a large hero banner at the very top of the DOM, before any significant headlines, leaving the browser with no choice but to select a slower LCP candidate.

では、テキストベースのLargest Contentful Paint要素に切り替えるべきでしょうか？それは状況によります。画像は重要であり、サイトを視覚的に魅力的にします。したがって、退屈なテキスト要素に切り替えるべきだと主張するつもりはありません。しかし、ミスも起こります。「意図しないLCP（Accidental LCP）」アンチパターンの犠牲になっているカテゴリページは数え切れないほど存在します。これは、ファーストビューに説明的なカテゴリテキストを追加し忘れたことで、lazy loadingされた商品画像がLCP要素になってしまい、読み込み時間が数秒も遅れるというものです。デザイナーが重要な見出しよりも前に、DOMの最上部に巨大なヒーローバナーを配置した場合に多く発生し、ブラウザはより遅いLCP候補を選択せざるを得なくなります。

2. 利用可能な最速の画像フォーマットを使用する

最後の1バイトまで削る方法や、WebP対AVIFの最適な設定についての激しい議論はさておき、一つの事実について合意しましょう。JPEGやPNGのような古いフォーマットは、WebPやAVIFのようなモダンなフォーマットと比較して、ファイルサイズが大きく低速です。画像最適化テクニックの全容については、画像最適化のガイドを参照してください。

原則として、LCP画像には非可逆圧縮のWebPまたはAVIFを使用すべきです（本来はすべての画像でこれらのフォーマットを使用するのが理想ですが、ここではLCPに焦点を当てます）。WebPのサポート率は約95%、AVIFのサポート率は92%に達していますが、古いブラウザ向けにfallback画像を提供することにも依然として意味があります。そのためには、これらのモダンなフォーマットをサポートしているブラウザにのみ提供する「プログレッシブエンハンスメント」を採用します。

デコード速度と圧縮率のトレードオフ

AVIFは最も優れた圧縮率（最小のファイルサイズ）を提供しますが、その複雑なアルゴリズムのため、WebPと比較して画像をデコードする際により多くのCPUパワーを必要とする場合があります。これはブラウザのラスタライザースレッドで実行されるCPUバウンドなタスクであり、Element Render Delayを直接増加させます。ファイルサイズの小さいAVIFはダウンロードこそ速いかもしれませんが、デコードに時間がかかるため、特にモバイルデバイスではそのメリットが打ち消される可能性があります。これは、Chrome DevToolsのPerformanceパネルで、LCP要素に関連する実行時間の長い「Decode Image」タスクを探すことで診断できます。これを確認できれば、ダウンロード時間だけでなく、デコード速度がボトルネックになっている明確なサインです。

エキスパートの視点：JPEG XLについて。本格的な解説を行うにあたり、JPEG XLに触れないわけにはいきません。これは技術的に極めて優れたフォーマットであり、特に既存のJPEGを可逆的に再圧縮できる点（レガシーサイトにとって大きなメリット）や、AVIFにはないプログレッシブデコードをサポートしている点が特徴です。しかし、致命的な欠点は、Chromeでのサポートが終了したことによる広範なブラウザサポートの欠如です。これにより、現時点では一般的なウェブ利用には適していませんが、将来に向けて注目すべき技術と言えます。

<picture>要素の使用：<picture>要素を使用すると、ブラウザはサポートしていない画像フォーマットをスキップし、処理可能な最初のフォーマットを選択できます。具体的な方法は以下の通りです。

<picture>
<source srcset="img.avif" type="image/avif">
<source srcset="img.webp" type="image/webp">
<img src="img.jpg" alt="Image" width="123" height="123">
</picture>

フォーマットネゴシエーションとレスポンシブサイズの組み合わせ

最高のパフォーマンスを得るには、単一の<picture>要素の中で、フォーマットの選択とレスポンシブ対応 of Image size （画像サイズ）を組み合わせる必要があります。これにより、すべてのユーザーがデバイスに最適なフォーマットかつ最適なサイズの画像を受け取ることができます。ブラウザは<source>要素を上から順に評価し、サポートしている最初のフォーマットを選択した上で、srcset属性とsizes属性を使用して適切な解像度を選択します。

<picture>
  <source
    type="image/avif"
    srcset="hero-400w.avif 400w, hero-800w.avif 800w, hero-1200w.avif 1200w"
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 800px, 1200px">
  <source
    type="image/webp"
    srcset="hero-400w.webp 400w, hero-800w.webp 800w, hero-1200w.webp 1200w"
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 800px, 1200px">
  <img
    src="hero-800w.jpg"
    srcset="hero-400w.jpg 400w, hero-800w.jpg 800w, hero-1200w.jpg 1200w"
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 800px, 1200px"
    alt="Descriptive alt text for hero image"
    width="1200" height="675"
    fetchpriority="high">
</picture>

このパターンにより、ブラウザはフォーマットと解像度の最適な組み合わせを完全に自由に選択できます。サポートされているブラウザを使用しているモバイルユーザーには小さなAVIFファイルが提供され、古いデスクトップブラウザは適切にサイズ調整されたJPEGにfallbackします。

コンテンツネゴシエーションの使用

コンテンツネゴシエーションを使用すると、ブラウザのサポート状況に基づいてサーバーから異なる画像フォーマットを配信できます。ブラウザはAcceptヘッダーを介して、サポートしているフォーマットを通知します。たとえば、Chromeにおける画像のAcceptヘッダーは以下のようになります。

Accept: image/avif,image/webp,image/apng,image/*,*/*;q=0.8

あとはサーバー側でAcceptヘッダーを読み取り、その内容に基づいて「最適なフォーマット」を配信します。

3. レスポンシブ画像を使用する

LCP画像の最適化において、サイズは極めて重要です。最も簡単な改善策の一つは、ユーザーの画面できれいに表示される範囲で、できる限り小さな寸法の画像を提供することです。必要以上に大きな画像は何の役にも立ちません。特に低速な回線やモバイルデバイスを使用しているユーザーにとって、帯域幅を無駄に消費し、ロード時間を遅くするだけです。

ピクセルを無駄にしないために、以下の手順に従ってください。

レスポンシブ画像：

srcset属性を使用して、ユーザーのデバイスに応じた異なる画像サイズを提供します。これにより、小さなデバイスには小さな画像が配信され、LCPの高速化に繋がります。

なぜsizes属性が極めて重要なのか

srcsetでw記述子を使用していながら、sizes属性を省略するのは、よくある大きなミスです。sizes属性がない場合、ブラウザはデフォルト値である100vw（viewport幅の100%）を強制的に適用します。その結果、たとえ画像がわずか500px幅のカラムに表示されるだけであっても、デスクトップの大画面ではブラウザがsrcsetリストから巨大な画像をダウンロードしてしまいます。これでは適切な材料（srcset）を用意したのにレシピ（sizes）を忘れた状態であり、帯域幅の無駄遣いとLCPの低下を招きます。sizes属性は必要なレイアウト情報を提供し、異なるviewport of browser（ブラウザのviewport）のブレイクポイントで画像が実際にどのくらいの幅で表示されるかをブラウザに伝えることで、賢い画像選択を可能にします。

w記述子とx記述子の違いを理解する

srcset属性は2種類の記述子をサポートしています。画像のサイズがviewportに合わせて変化するレスポンシブデザインでは、w（幅）記述子が不可欠かつ最適な選択肢となります。sizes属性と併用することで、レイアウト上での実際の表示サイズに基づいてブラウザに最適な画像を選択させることができます。よりシンプルなx（デバイスピクセル比）記述子は、画面のピクセル密度のみを考慮し、レイアウト内での画像の大きさは無視するため、アイコンなどの固定サイズ画像にのみ適しています。

<img
  src="img.jpg"
  srcset="img-400px.jpg 400w, img-800px.jpg 800w, img-1200px.jpg 1200w"
  sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
  alt="Image" width="123" height="123">

4. 画面サイズに合わせて画像をスケーリングする！

必要以上に大きな画像を配信するのは避けてください。LCP要素がviewport内で600px幅しかない場合、画像もそれより大きくならないようにします。これは本当によくあるミスで、毎日のように目にします！確認するには、画像を右クリックして「検証」を選択してください。デベロッパーツールが開き、画像のHTMLがハイライトされます。ここで、画像の表示サイズ（443 x 139px）が画像本来のサイズ（1090 x 343px）よりもはるかに小さいことがわかります。本来のサイズは表示サイズの約3倍もあり、画像をリサイズするだけでファイルサイズを少なくとも50%は削減できたはずです。

5. LCP画像にはeager loadingを使用する

LCPのパフォーマンスを最大限に引き出すには、表示されているLCP要素をeager loadingする必要があります（すぐに見えない画像はlazy loadingします）。これはLCP最適化において最もよくあるミスの一つであり、詳細はLCP画像がlazy loadingされていた場合の修正方法の記事で詳しく解説しています。

Eager loading：LCP要素（通常はファーストビュー内のコンテンツ）は常にeager loadingする必要があります。これにより要素ができるだけ早く表示され、Largest Contentful Paintがレンダリングされるまでの時間が短縮されます。特に指定がない限り、画像はデフォルトでeager loadingされますが、LCP画像にloading="lazy"が設定されていないか再確認してください。これが設定されていると、LCPが大幅に遅れ、Core Web Vitalsのスコアに悪影響を及ぼします。loading="eager"はブラウザのデフォルトの挙動であるため、属性自体を省略しても同じ効果があることを理解してください。極めて重要なのは、loading="lazy"が指定されていないことを確認することです。

技術解説：lazy loadingされた画像は、preload scannerのキューに入りません。preload scanner is a super fast secondary HTML scanner（preload scannerは重要なリソースを即座にキューイングする超高速のセカンダリHTMLスキャナーです）。preload scannerがバイパスされると、ブラウザはレンダリングエンジンの処理が完了するのを待ってから「表示対象の画像」をキューに入れることになります。ブラウザがネイティブのloading="lazy"を評価するには、まずすべてのrender blockingなCSSをダウンロードして解析し、レンダーツリーを構築する必要があります。レイアウトが計算されて初めて、ブラウザはその画像がviewport内にあるかどうかを判断できます。つまり、CSS全体がLCP画像のダウンロード開始をブロックする依存関係になってしまい、パフォーマンス上の大惨事につながります。

<img src="lcp-image.jpg" alt="Main image" width="800" height="400">

ファーストビューより下（ページ読み込み時に見えない領域）に表示される画像については、lazy loadingを使用するのが最善です。ユーザーがその画像の近くにスクロールするまで読み込みを遅らせることで、LCP要素のようなより重要なコンテンツのために帯域幅を空けることができます。このように、lazy loadingは諸刃の剣です。正しく使えばLCPコンテンツを高速化できますが、誤って使うと低速化を招きます！

<img src="non-visible-image.jpg"
     alt="Secondary image"
     loading="lazy" 
     width="800" height="400">

適切なバランスとは？重要なコンテンツ（LCP画像など）はeager loadingし、重要性の低いリソースやファーストビューより下の画像はlazy loadingすることです！

6. LCP画像をプリロードする

LCP画像をプリロードすることで、ブラウザがHTML内で通常通りに画像を見つける前に、即座にフェッチするように指示できます。プリロードに関する完全なガイドについては、LCP画像のプリロードに関する専用記事を参照してください。

なぜLCP画像をプリロードするのか？

ブラウザがページを読み込む際、HTML、スタイルシート、スクリプトは特定の順序で処理されます。LCP画像が処理フローの後半で参照されている場合、ブラウザの処理開始が本来よりも遅れてしまいます。LCP画像をプリロードすることで、その画像が極めて重要であり、即座に読み込むべきであることをあらかじめブラウザに伝え、最大要素のレンダリング遅延を減らすことができます。

LCP画像をプリロードする方法

<link rel="preload">タグを使用することで、読み込みプロセスの初期段階でブラウザにLCP画像の取得を開始させることができます。

<link rel="preload" href="lcp-image.jpg" as="image" type="image/jpeg">

これにより、LCP画像が最初からブラウザの読み込みキューに入り、画像がCSSやスクリプトの中に埋もれている場合に発生しがちな読み込み待ちを避けることができます。

エキスパートの視点：レスポンシブプリロードと`fetchpriority`

レスポンシブ画像の場合、単純なプリロードだけでは不十分です。パフォーマンスを低下させる重複ダウンロードを避けるには、プリロード用リンク自体にimagesrcset属性とimagesizes属性を指定し、<img>タグのロジックと一致させる必要があります。これこそが、卓越したパフォーマンスを発揮するサイトとその他を分ける、エキスパートレベルの実装です。

<!-- In the <head> -->
<link rel="preload" as="image"
      href="lcp-image-800w.jpg"
      imagesrcset="lcp-image-400w.jpg 400w, lcp-image-800w.jpg 800w"
      imagesizes="(max-width: 600px) 400px, 800px">

<!-- In the <body> -->
<img src="lcp-image-800w.jpg"
     srcset="lcp-image-400w.jpg 400w, lcp-image-800w.jpg 800w"
     sizes="(max-width: 600px) 400px, 800px"
     alt="..." width="800" height="450" fetchpriority="high">

<img>タグにfetchpriority="high"を指定することで、プリロードがサポートされていない場合でも確実に画像が優先されるようなfallbackを提供できます。これは「念には念を入れる」対策です。プリロードでダウンロードを早期に開始し、fetchpriorityで帯域幅の獲得競争を確実に勝ち抜きます。

注意：プリロードするのはLCP画像のみに留めてください。あまりに多くのリソースをプリロードすると、ブラウザに負荷がかかり、かえってパフォーマンスが低下します。Core Web Vitalsにとって最も重要な要素に絞って適用しましょう。

7. LCP画像からフェードインアニメーションを削除する

フェードインアニメーションは視覚的に魅力的ですが、LCPの隠れたボトルネックになります。LCP要素（多くの場合画像）にフェードイン効果が使用されている場合、ブラウザはアニメーションが完了するまでLCPを記録しません。これによりLCPの計測タイミングが遅れ、パフォーマンス指標を大きく悪化させる可能性があります。

エキスパートの視点：アニメーションによる遅延のメカニズム

この問題はフェードインだけに留まりません。スライドイン（例：transform: translateX(-100%)から開始）やズーム効果（例：transform: scale(0.5)から開始）のように、初期状態で非表示または画面外にある要素を遷移させるあらゆるアニメーションに当てはまります。LCPの測定ロジックは、最大の要素が視覚的に安定し、完成した瞬間を捉えるように設計されています。アニメーション中の要素は安定していると見なされません。ブラウザはすでに画像をダウンロードしているにもかかわらず、アニメーションが終了するまで最終フレームを描画できないため、LCPを構成する要因の一つであるElement Render Delayが直接増加します。

LCPの計測タイミングはアニメーション終了後：ブラウザは、要素が完全に表示されたときに初めてLCPが完了したと見なします。フェードインアニメーションが適用されていると、画像やコンテンツが完全に表示されきるまでタイマーが回り続けるため、LCPスコアに余計な時間が簡単に追加されてしまいます。

シンプルに保つ：LCP要素をできるだけ早く表示させるために、フェードイン効果の使用は避けてください。トランジションやアニメーションを一切挟まず、画像を即座にロードして表示させます。

LCP画像でのフェードインは止めましょう。その視覚効果は、パフォーマンス低下の代償に見合うものではありません。

8. LCP要素をセルフホストする

LCP画像をセルフホストしてください。サードパーティのサーバーに依存すると、管理できない遅延が発生し、LCPやページ全体のパフォーマンスを悪化させる原因になります。

たとえて言うなら：LCP要素をセルフホストしないのは、近所の人から常に砂糖を借りているようなものです。毎回、隣の家まで歩いていき、玄関で待たされ、相手が在宅していることを祈る必要があります。LCPをサードパーティのサーバーに依存すると、サイトはその外部リソースを待つことになり、ロードタイムが遅くなります。セルフホストは、砂糖を自分のキッチンに置いておくようなものです。高速で、直接的で、信頼性があります。

外部依存関係の削減：LCP要素（画像など）がサードパーティのサーバーでホストされていると、そのサーバーの応答速度や稼働状況、追加のラウンドトリップタイム（RTT）に左右されます。セルフホストはこの不確実性を排除し、自身のサーバーから直接画像を配信できるようにするため、より高速で確実な配信が可能になります。

エキスパートの視点：単一オリジンとしてのモダンなCDN

基本原則は、新しいオリジンへの接続（DNS、TCP、TLS）を最小限に抑えることです。最も高度なアーキテクチャは、ドメイン全体のリバースプロキシとしてモダンなCDNを利用することでこれを実現します。ブラウザから見れば、接続するオリジンは常に1つ（例：www.yourdomain.com）のみとなるため、接続のペナルティが完全に解消されます。その後、CDNがバックグラウンドでリクエストを賢くルーティングし、オリジンサーバーから動的コンテンツを取得しながら、画像などの静的アセットをエッジキャッシュから配信します。この単一接続がHTTP/3で処理されれば、オリジンの統一、接続セットアップ時間の短縮、ヘッドオブラインブロッキングの緩和など、あらゆるメリットが得られます。

キャッシュと最適化の利用：セルフホストを行うことで、キャッシュ戦略を最大限に活用できます。特にCDNを使用している場合、ユーザーに最も近いサーバーから画像を配信できるようになります。これによりLCP要素のロードにかかる時間が短縮され、結果としてレンダリングが高速化します。

画像最適化の完全な制御：セルフホストを行うと、サードパーティの処理に依存することなく、圧縮、リサイズ、フォーマット選択など、画像の最適化方法をコントロールできます。これにより、画像を高速読み込みに最適化された状態に保つことができます。

9. LCP要素におけるクライアントサイドレンダリングを避ける

クライアントサイドレンダリング（CSR）は、LCPに最悪の影響を与える要因の一つです。LCP要素（通常は巨大な画像、テキストブロック、または動画）がJavaScriptを介してクライアントサイドでレンダリングされると、ブラウザが重要なコンテンツを表示する前にスクリプトのダウンロード、解析、実行を待つ必要があるため、LCPスコアが著しく低下します。

レンダリングの遅延：CSRを使用すると、ブラウザがJavaScriptを処理し終えた後に初めてLCP要素が表示されるため、表示のタイミングが大幅に遅れます。この処理に時間がかかるほど、LCPスコアは悪化します。スクリプト処理に費やされる余計な時間は、ユーザーが最も重要なコンテンツを目にするまでの待ち時間そのものになります。

エキスパートの視点：なぜCSRがLCPを悪化させるのか

CSRがLCPにもたらす最大のデメリットは、ブラウザの高速なpreload scannerからLCP画像が隠されてしまうことです。このスキャナーの役割は、初期のHTMLからリソースを見つけ出して即座に取得することです。画像がJavaScriptでレンダリングされる場合、スキャナーはそれを検出できないため、画像が発見されるまでに大きなタイムラグが生じます。

サーバーサイドレンダリング（SSR）または静的レンダリングへの切り替え：LCP要素をサーバーサイド、または静的HTMLレスポンスの一部としてレンダリングすることで、JavaScript의 実行を待つことなく、ブラウザが画像を即座に読み込んで表示できるようになります。ブラウザはHTMLの読み込み開始と同時にLCP要素をレンダリングできるため、LCPのタイミングが劇的に改善されます。

クリティカルパス上のJavaScriptの最小化：クライアントサイドのスクリプトを排除できない場合は、それらがLCP要素のレンダリングをブロックしないように対策します。重要ではないスクリプトにはdeferまたはasyncを指定し、LCPの表示遅延を防いでください。

10. レイアウトシフトを防ぐために表示領域を確保する

<img>タグには、常に明示的なwidth属性とheight属性を指定してください。これはブラウザに対する重要な指示であり、画像がダウンロードされる前にアスペクト比を計算して、レイアウト上に適切なスペースを確保させることができます。

エキスパートの視点：モダンブラウザにおけるwidthとheightの挙動

よくある誤解として、これらの属性を指定すると画像がレスポンシブに対応できなくなるというものがありますが、現在のモダンブラウザではそのようなことはありません。ブラウザはHTMLの属性値からアスペクト比を計算して表示領域を確保しますが、CSS側でwidth: 100%; height: auto;を設定しておけば、画像は完全にレスポンシブとして機能します。これらの属性を指定することは、CSSのaspect-ratioプロパティのみを使う方法よりも優れています。なぜなら、render blockingなCSSがダウンロード・解析される前にスペースを確保でき、処理を一歩リードできるからです。

CSS背景画像の取り扱い

この原則は、CSSのbackground-imageを表示するコンテナ要素にも当てはまります。レイアウトシフトの典型例として、初期状態では高さが0に潰れており、背景画像が適用された瞬間に突然サイズが拡張される<div>要素が挙げられます。これを防ぐには、コンテナ要素に直接CSSのaspect-ratioプロパティを指定し、最初から必要なスペースを確保してください。

11. main threadのブロックを監査する

LCP画像がどれほど最適化され、優先順位付けされていても、ブラウザのmain threadが重いJavaScriptの実行で占有されていると、最終的なレンダリングが遅れます。多くの場合、このブロックの原因は分析、広告、カスタマーサポートのウィジェットなどのサードパーティスクリプトです。これらのスクリプトがCPUを占有し、Element Render Delayを増加させます。Chrome DevToolsのPerformanceパネルを使用して、初回ロード時に発生しているlong taskを特定し、その発生元を特定した上で、初回レンダリングに不要なものは遅延させるか削除してください。詳細については、Element Render Delayのガイドを参照してください。