Largest Contentful Paint 画像を最適化する

Largest Contentful Paint 画像を最適化する

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

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

これらの要素はすべて重要ですが、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 と同時に発生します。

それでは、テキストベースの Largest Contentful Paint 要素に切り替えるべきでしょうか？それは状況によります！画像は重要であり、サイトを視覚的に魅力的にします。つまり、私が退屈な古いテキスト要素に切り替えることを推奨することはありません。しかし、間違いも起こります！「偶発的な LCP（Accidental LCP）」アンチパターンの犠牲になったカテゴリページを見るたびに、1ドルもらえればいいのにと思います。これは、ページがファーストビューに説明的なカテゴリテキストを追加するのを「忘れ」、遅延読み込みされる製品画像が LCP となり、読み込み時間が数秒遅延するケースです。これは、デザイナーが大きなヒーローバナーを DOM の一番上、重要な見出しの前に配置したため、ブラウザがより遅い LCP 候補を選択せざるを得なくなった場合によく発生します。

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

最後の1バイトを絞り出すための激しい議論や、WebP と AVIF の完璧な設定についての議論に深入りすることなく、1つのことについて同意しましょう。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> 要素内でフォーマットの選択とレスポンシブな画像サイズを組み合わせる必要があります。これにより、すべてのユーザーが自分のデバイスに最適なフォーマットと最適なサイズを取得できるようになります。ブラウザは <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 画像の最適化において、サイズは非常に重要です。最も簡単に効果を上げる方法の1つは、ユーザーの画面で見栄え良く表示される、可能な限り最小の寸法の画像を提供することです。大きな画像は全く機能しません。帯域幅を無駄にし、特に低速な接続を使用しているユーザーやモバイルデバイスでは、読み込み時間を遅くします。

ピクセルを無駄にしないために、以下のステップに従ってください:

レスポンシブ画像:

srcset 属性を使用して、ユーザーのデバイスに基づいて異なる画像サイズを提供します。こうすることで、小さなデバイスには小さな画像が提供され、LCP を高速化するのに役立ちます。

sizes 属性が不可欠な理由

w 記述子を持つ srcset を使用しながら、sizes 属性を省略するのは、よくある大きな犠牲を伴う間違いです。sizes 属性がないと、ブラウザはデフォルト値の 100vw（ビューポート幅の100%）を想定せざるを得ません。つまり、画像が小さな 500px の列にしか表示されない場合でも、ブラウザは大型デスクトップ画面では srcset リストから巨大な画像をダウンロードすることになります。適切な材料（srcset）を提供しても、レシピ（sizes）を省略したため、帯域幅の無駄と LCP の低下を招いているのです。sizes 属性は必要なレイアウトコンテキストを提供し、さまざまなビューポートブレークポイントで画像の幅が実際にどのくらいになるかをブラウザに伝え、インテリジェントなダウンロードの選択を可能にします。

w と x 記述子の理解

srcset 属性は2種類の記述子をサポートしています。ビューポートに応じて画像のサイズが変わるレスポンシブデザインでは、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 要素がビューポート内で 600px の幅しかない場合は、画像の大きさがそれ以下であることを確認してください。私を信じてください、私はこれが毎日起こるのを見ています！確認するには、画像を右クリックして「要素を検査（inspect-element）」を選択し、画像を検証するだけです。開発ツールが表示され、画像の HTML が青い背景でハイライトされます。ここで、画像のレンダリングサイズ（443 x 139px）が固有の画像幅（1090x343px）よりもはるかに小さいことがわかります。これはほぼ3倍の大きさであり、画像のサイズを変更すれば、ファイルサイズの少なくとも50%を節約できたはずです。

5. Eager ロードされた LCP 画像を使用する

LCP のパフォーマンスを最大限に引き出すには、表示されている LCP 要素を Eager ロードし（すぐに表示されない画像は遅延読み込みし）る必要があります。これは LCP 最適化における最も一般的な間違いの1つであり、遅延読み込みされた LCP 画像の修正に関する記事で詳しく解説しています。

Eager ロード: LCP 要素（通常はファーストビューのコンテンツ）は、常に Eager ロードされるべきです。これにより、可能な限り早く表示され、Largest Contentful Paint のレンダリングにかかる時間を短縮できます。デフォルトでは、特に指定がない限り画像は Eager ロードされますが、LCP 画像に loading="lazy" を設定していないか再確認してください。これを設定すると、LCP が大幅に遅延し、Core Web Vitals スコアが低下する可能性があります。loading="eager" がブラウザのデフォルトの動作であるため、属性を完全に省略しても同じ効果があることを理解することが重要です。重要なのは、loading="lazy" が存在しないことを確認することです。

ギークアラート: 遅延画像はプリロードスキャナーによってエンキューされません。プリロードスキャナーは、重要なリソースを即座にエンキューする超高速なセカンダリ HTML スキャナーです。プリロードスキャナーがバイパスされると、ブラウザは「可視画像」をエンキューする前にレンダリングエンジンの完了を待たなければならなくなります。ブラウザがネイティブの loading="lazy" を評価するには、まずレンダリングブロックするすべての CSS をダウンロードしてパースし、レンダーツリーを構築する必要があります。レイアウトが計算されて初めて、ブラウザは画像がビューポート内にあるかどうかを判断できます。つまり、CSS 全体が LCP 画像のダウンロードのブロッキング依存関係になり、これはパフォーマンス上の大惨事です。

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

スクロールせずに見えない部分にある画像（ページが最初に読み込まれたときに表示されない画像）については、遅延読み込み（lazy loading）が最適です。これらの画像の読み込みを、ユーザーがその近くにスクロールするまで遅らせることで、LCP 要素のようなより重要なコンテンツのために帯域幅を解放できます。この意味で遅延読み込みは両刃の剣です。正しく使えば LCP コンテンツを高速化しますが、間違って使えば遅速化させます！

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

バランスは？重要なコンテンツ（LCP 画像など）は Eager ロードし、重要度の低いリソースやスクロールせずに見えない部分にある画像は遅延読み込みします！

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 やスクリプトの中に埋もれている場合によく発生する待機時間を回避できます。

<!-- 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">

覚えておいてください: リソースをプリロードしすぎるとブラウザを圧倒し、パフォーマンスを低下させる可能性があるため、LCP 画像のみをプリロードしてください。Core Web Vitals にとって最も重要なことに集中してください。

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

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

LCP のタイミングはアニメーション終了後に発生します: ブラウザは、要素が完全に表示された場合にのみ LCP が完了したと見なします。フェードインアニメーションがある場合、画像やコンテンツが完全にフェードインするまでタイマーは作動し続けるため、LCP スコアに簡単に数秒の追加時間が加わってしまいます。

シンプルに保つ: LCP 要素を可能な限り早く表示するには、フェードイン効果の使用を避けてください。トランジションやアニメーションなしで、画像をすぐに読み込んで表示させましょう。

LCP 画像でのフェードインはスキップしてください。視覚的な効果はパフォーマンスコストに見合いません。

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

LCP 画像をセルフホストしてください。サードパーティのサーバーに依存すると、制御できない遅延が発生し、LCP および全体的なページのパフォーマンスが低下する可能性があります。

このように考えてみてください: LCP 要素をセルフホストしないことは、常に隣人に砂糖を借りているようなものです。毎回歩いて行き、ドアの前で待ち、彼らが家にいることを願わなければなりません。LCP をサードパーティのサーバーに依存すると、Web サイトはその外部リソースを待つことになり、読み込み時間が遅くなります。セルフホスティングは、キッチンの砂糖を保管しておくようなものです。速く、直接的で、信頼性があります。

外部依存関係を減らす: LCP 要素（画像など）がサードパーティのサーバーでホストされている場合、そのサーバーの速度、可用性、および追加のラウンドトリップタイム（RTT）に左右されます。セルフホスティングにより、この不確実性が排除され、画像をご自身のサーバーから直接提供できるようになり、より高速で信頼性の高い配信が保証されます。

キャッシュと最適化の使用: セルフホストすることで、キャッシュ戦略を最大限に活用し、特に CDN を使用している場合は、ユーザーに最も近いサーバーから画像を提供できます。これにより、LCP 要素の読み込みにかかる時間が短縮され、より高速なレンダリングが可能になります。

画像最適化の制御: セルフホスティングにより、圧縮、サイズ変更、フォーマットの選択など、サードパーティの処理に依存することなく画像の最適化方法を制御できます。このようにして、画像が高速な読み込みのために完璧に調整されていることを確認できます。

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

クライアントサイドレンダリング（CSR）は、LCP に対してできる最悪のことの1つです。LCP 要素（通常は大きな画像、テキストブロック、または動画）が JavaScript を介してクライアント側でレンダリングされる場合、ブラウザが重要なコンテンツを表示する前にスクリプトのダウンロード、パース、実行を待たなければならないため、LCP 時間が遅くなることがよくあります。

レンダリングの遅延: CSR では、ブラウザが JavaScript を処理した後にのみ LCP 要素が表示されるため、その表示が大幅に遅れる可能性があります。これに時間がかかるほど、LCP スコアは悪化します。スクリプトの処理に1秒余分にかかるごとに、ユーザーが最も重要なコンテンツを見るまでの待ち時間が長くなります。

サーバーサイドレンダリング（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 をダウンロードしてパースする前に、必要なスペースを確保でき、重要なスタートダッシュを切ることができるため、これらの属性を提供することは、CSS の aspect-ratio プロパティのみを使用するよりも優れています。

CSS バックグラウンド画像の処理

この原則は、CSS background-image のコンテナとして機能する要素にも当てはまります。レイアウトシフトの一般的な原因は、最初は高さゼロに折りたたまれており、バックグラウンド画像が適用されたときにサイズが急に大きくなる <div> です。これを防ぐには、コンテナ要素に CSS の aspect-ratio プロパティを直接使用して、最初から必要なスペースを確保します。

11. メインスレッドのブロッキングを監査する

LCP 画像が完全に最適化され、優先順位が付けられていたとしても、ブラウザのメインスレッドが重い JavaScript の実行でビジー状態にあると、最終的なレンダリングが遅延する可能性があります。多くの場合、このブロッキングの原因は、分析、広告、またはカスタマーサポートウィジェット用のサードパーティスクリプトです。これらのスクリプトは CPU を独占し、Element Render Delay を増加させる可能性があります。Chrome DevTools の Performance パネルを使用して、初期読み込み中の実行時間が長いタスクを特定し、そのソースを特定して、初期レンダリングに不可欠でないものは defer または削除します。このトピックの詳細については、Element Render Delay のガイドを参照してください。

関連する LCP 最適化ガイド

画像の最適化はパズルの一片にすぎません。各 LCP フェーズにはそれぞれのガイドがあります:

• LCP の問題を特定して修正する: フィールドデータとラボツールを使用して LCP の問題を見つけ、修正するための完全な診断方法。
• Resource Load Delay: プリロード、fetchpriority、および最適な HTML 構造により、ブラウザができるだけ早く LCP リソースを検出できるようにします。
• Resource Load Duration: 圧縮、CDN 構成、およびネットワーク最適化によってダウンロード時間を短縮します。
• Element Render Delay: ブラウザがダウンロード直後に LCP 要素を描画できるように、メインスレッドをクリアします。