Largest Contentful Paint 画像を最適化してください。

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

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

Googleによれば、インターネット上の全ページビュー（デスクトップとモバイルを含む）のうち、「良好」なLargest Contentful Paintスコアを獲得しているのはわずか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」アンチパターンの犠牲になったカテゴリページを見るたびに1ドルもらえたら、大金持ちになれるでしょう。これは、ページがスクロールせずに見える範囲に説明的なカテゴリテキストを追加し忘れ、lazy loadingされた商品画像が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属性が不可欠な理由

srcsetにw記述子を使用しながらsizes属性を省略するのは、よくある代償の大きいミスです。sizes属性がないと、ブラウザはデフォルト値の100vw（viewportの幅の100%）を想定せざるを得ません。つまり、大きなデスクトップ画面では、画像が500pxの小さなカラムにしか表示されない場合でも、ブラウザはsrcsetリストから巨大な画像をダウンロードします。正しい材料（srcset）を用意しても、レシピ（sizes）を忘れたため、帯域幅が無駄になりLCPが遅くなります。sizes属性は必要なレイアウトコンテキストを提供し、異なる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. 画面サイズに合わせて画像をスケーリングする

必要以上に大きな画像の配信は避けてください。viewport内でLCP要素の幅が600pxしかない場合、画像のサイズもそれ以下に抑えてください。信じてください、私はこの問題を毎日目にしています。確認するには、画像を右クリックして「要素を検査」を選択するだけです。DevToolsが開き、画像のHTMLが青い背景でハイライトされます。画像のレンダリングサイズ（443 x 139px）が、画像本来の幅（1090x343px）よりもはるかに小さいことがわかります。これはほぼ3倍の大きさであり、画像をリサイズすればファイルサイズを少なくとも50%削減できたはずです。

5. LCP画像にはEager Loadingを使用する

LCPから最高のパフォーマンスを引き出すには、目に見えるLCP要素をeager loadし、すぐには見えない画像をlazy loadすべきです。これはLCPの最適化で最もよくあるミスの1つであり、lazy loadingされたLCP画像の修正に関する記事で詳細に解説しています。

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

技術的な警告：lazy loadingされる画像は、プリロードスキャナーのキューに入りません。プリロードスキャナーは、重要なリソースを直ちにキューに入れる超高速なセカンダリHTMLスキャナーです。プリロードスキャナーがバイパスされると、ブラウザは「可視画像」をキューに入れる前に、レンダリングエンジンの完了を待たなければなりません。ブラウザがネイティブの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 loadし、重要度の低いリソースやスクロールしないと見えない範囲の画像はlazy loadすることです。

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

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

<!-- <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をサードパーティのサーバーに依存すると、ウェブサイトはその外部リソースを待つことになり、読み込み時間が遅くなります。セルフホスティングは、キッチンに砂糖を置いておくようなものです。速く、直接的で、信頼性があります。

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

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

画像の最適化をコントロールする：セルフホスティングにより、サードパーティの処理に依存することなく、圧縮、リサイズ、フォーマット選択など、画像の最適化方法をコントロールできます。これにより、高速読み込みのために画像を完璧に調整できます。

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

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

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

サーバーサイドレンダリング（SSR）または静的レンダリングに切り替える：サーバー側、または静的なHTMLレスポンスの一部としてLCP要素をレンダリングすることで、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のコンテナとして機能する要素にも当てはまります。レイアウトシフトの一般的な原因は、最初は高さがゼロに潰れていて、背景画像が適用されたときにサイズが拡大する<div>です。これを防ぐには、コンテナ要素に直接CSSのaspect-ratioプロパティを使用し、最初から必要なスペースを確保します。

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

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

ステップバイステップガイド：Chrome DevToolsのPerformanceパネルによるLCPの診断では、スロットル状態でのトレースを記録し、Mainトラックでこれらのlong taskを見つける方法を解説しています。

関連するLCP最適化ガイド

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

• LCPの問題を特定して修正する：field dataとラボツールを使用してLCPの問題を見つけ、修正するための完全な診断手法。
• Resource Load Delay：preload、fetchpriority、および最適なHTML構造を使用して、ブラウザがLCPリソースを可能な限り早く検出できるようにします。
• Resource Load Duration：圧縮、CDN構成、ネットワークの最適化を通じてダウンロード時間を短縮します。
• Element Render Delay：ダウンロード直後にブラウザがLCP要素を描画できるように、main threadを空けておきます。