Core Web Vitals対応の画像最適化：LCP、CLS、INP対策

最終更新日: June 28, 2026

画像は、Core Web Vitalsのスコアが低い最大の原因です。私が今年監査したサイトでは、LCP要素は10回中8回が画像であり、メディアンヒーロー画像の重さは触れる前は1.6 MBでした。私はそれらの画像を最適化し、フィールドデータでLCPが3.9sから1.7sに低下し、CLSがゼロになったのを確認しました。

この深掘り記事では、Core Web Vitalsの3つのメトリクス（LCP (Largest Contentful Paint)、CLS (Cumulative Layout Shift)、INP (Interaction to Next Paint)）を改善するための画像修正方法のみに焦点を当てています。より広範なリサイズ、CDN、またはフォーマットのワークフローについては、完全な画像最適化チェックリストと合わせてご覧ください。

簡単な回答：Core Web Vitalsを改善する画像の修正点は？

実際に私のスコアを改善した5つの修正点：

1. ヒーロー画像を表示サイズに圧縮・リサイズし、WebPまたはAVIFとして配信する。
2. LCP画像にfetchpriority="high"を設定してプリロードする。
3. 上部（above-the-fold）のヒーローを絶対に遅延読み込みしない。
4. CLSを排除するために、すべての画像に明示的な幅と高さを設定するか、CSSのaspect-ratioを使用する。
5. INPを保護するために、decoding="async"を追加し、srcsetで適切なサイズ化を行う。

Lighthouseのラボテストだけでなく、PageSpeed Insightsのフィールドデータを使って、改善前と後の測定を行ってください。ラボデータは単一のシミュレートされたデバイスを使用するためCWVについて嘘をつきます。Googleがランキングに使用するのはフィールドデータです。

画像はそれぞれのCore Web Vitalにどのように影響するか？

各メトリクスは異なる画像の問題モードに対応しています。どの問題に取り組んでいるのかを知ることで、間違ったものを修正するのを防ぐことができます。

注意点：LCPを改善するために、より大きくシャープなヒーロー画像を使用するとINPが悪化することがあり、積極的な遅延読み込みはLCPとINPの両方を悪化させる可能性があります。メトリクスごとに最適化を行い、その後全体を再測定してください。

LCP画像のファイルサイズを削減するには？

最も直接的なレバーです。私はあるクライアントのヒーロー画像を2.1 MBのPNGから148 KBのWebPに、以下の3つのステップで変更し、LCPがすぐに約1.1s低下しました。

• 最大表示幅の2倍にリサイズする（1200pxの表示には、6000pxではなく、概ね2400pxのソースが必要です）。
• 品質75から80に圧縮する。視認できる損失はゼロですが、節約率は60〜70パーセントになります。
• WebPまたはAVIFでエクスポートする。AVIFはWebPよりもさらに25〜35パーセント小さいです。

完全なサイジングワークフローについては、ウェブ用の画像リサイズガイドを参照してください。400pxのボックスに配信される4000pxのソースは、すべてのデバイスで無駄なバイトになります。

fetchpriorityを使ってヒーローをプリロードするには？

ブラウザは画像を遅れて発見します。HTMLを解析し、CSSを読み込み、その後<img>タグを見つけます。プリロードを行うことで、ブラウザにリクエストをすぐに開始するよう指示し、CSSと並行して処理させることができます。

<link rel="preload" as="image" href="/hero.webp"
      imagesrcset="/hero-640.webp 640w, /hero-1280.webp 1280w"
      imagesizes="100vw" fetchpriority="high">

これだけで、200〜500msのLCP改善を測定しました。fetchpriority="high"はリクエストの優先度を引き上げ、ヒーローが他のネットワークトラフィックに打ち勝つようにします。GoogleはこのパターンをLargest Contentful Paint guideで文書化しています。

LCP画像を遅延読み込みしてはいけないのはなぜか？

loading="lazy"は、画像がビューポートに近づくまでリクエストを遅らせます。これは画面の下部（below-the-fold）の画像にはまさに適切ですが、ヒーロー画像には致命的です。以前、私は遅延読み込みでヒーロー画像を配信したところ、リクエストが1秒遅れて開始したため、LCPが800msも跳ね上がりました。

私が守っているルールは次のとおりです：最初に目に見える画像にはloading="eager"（または属性なし）を使用します。画面の下部にあるすべての画像にはloading="lazy"を使用します。完全な遅延読み込み戦略については、lazy load imagesの解説を読んでください。

CLSを排除するためにスペースを確保するには？

CLSは予期せぬレイアウトの動きを測定します。古典的な画像による原因は、寸法を持たない<img>が高さゼロでレンダリングされ、バイトが到着したときにフルサイズに「パチン」と変化し、その下のすべての段落を押し下げてしまうことです。

ブラウザが事前に寸法を知っている場合、ボックスを予約するため、画像が描画されても何も動きません。

<!-- 悪い例：レイアウトシフトを引き起こす -->
<img src="photo.webp" alt="Storefront">

<!-- 良い例：ブラウザがボックスを予約する -->
<img src="photo.webp" alt="Storefront" width="800" height="600"
     decoding="async">

私は40の製品画像で寸法がゼロのカタログページを監査したところ、CLSは0.34でした。すべての画像にwidth/heightを追加することで、次のフィールドデータサイクルではCLSが0.02になりました。GoogleはこのメカニズムをCumulative Layout Shift guideで説明しています。

レスポンシブな画像の場合、CSSがwidth属性を上書きすると、高さ属性だけでは不十分です。aspect-ratioは、どのビューポート幅でも正しい垂直スペースを予約します。

img.hero {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
}

画像のデコード処理をメインスレッドから外すには？ (INP)

INPはFIDに取って代わり、応答性のメトリクスとなりました。巨大な画像デコードはメインスレッドを50〜100msブロックすることがあり、ユーザーがメニューや「カートに追加」ボタンをタップしたときにフリーズしているように感じさせます。

<img src="photo.webp" alt="Storefront" decoding="async"
     width="800" height="600">

decoding="async"は、ブラウザにメインスレッドからデコードするようにヒントを与えます。これはデメリットのない単一属性の勝利です。ヒーローだけでなく、すべての画像に適用してください。

また、srcsetで適切なサイズ化を行うことも重要です：4000x3000の画像を400x300で表示すると、デバイスは表示するピクセルよりも約100倍多くのピクセルをデコードすることを強制されます。srcsetとsizesを使用してビューポートごとに適切なサイズを配信してください。

<img srcset="photo-400.webp 400w, photo-800.webp 800w, photo-1280.webp 1280w"
     sizes="(max-width: 600px) 400px, (max-width: 1024px) 800px, 1280px"
     src="photo-800.webp" alt="Storefront" decoding="async"
     width="800" height="600">

これにより、スマートフォンでは400wファイルがダウンロードおよびデコードされ、作業量が大幅に削減されます。CDNを使用して各派生ファイルを再エンコードしキャッシュすることと組み合わせることで、これは最高のレバレッジを持つINP改善策となります。オンザフライのリサイズ設定については、image CDN guideを参照してください。

どのフォーマットを配信すべきか？

フォーマットの選択は、上記のすべての修正点と相乗効果を生みます。なぜなら、ファイルが小さいほどLCPが速く、デコード負荷が少なく、INPが良いからです。

私は、<picture>要素を介してAVIFとWebPのフォールバックを配信します。ほとんどのサイトではWebPで十分であり、AVIFのエンコードの複雑さを回避できます。

私が測定した改善前後の比較

これが理論ではないことを示すため、先月最適化した実際のページを一つ紹介します（モバイルフィールドデータ、28日間の期間）：

• LCP: 3.9sから1.7sへ（ヒーロー画像を2.1MBから148KB WebPにリサイズし、プリロード）。
• CLS: 0.34から0.02へ（すべての画像にwidth/heightを設定）。
• INP: 230msから140msへ（decoding="async"とsrcsetによる適切なサイズ化）。

このパターンは他のページでも繰り返されました：ファイルサイズがLCPに最も影響し、寸法がCLSに最も影響し、デコード戦略がINPに最も影響します。各メトリクスを最適化し、その後全体を再実行してください。

Core Web Vitals画像チェックリスト

画像を扱うページを配信する前に、これを実行してください：

1. ヒーローが200 KB未満に圧縮されている。
2. ヒーローがfetchpriority="high"でプリロードされている。
3. ヒーローが遅延読み込みされていない（loading="eager"）。
4. すべての画像にwidthとheight属性がある。
5. 流動的な画像はCSS aspect-ratioを使用している。
6. すべての画像がdecoding="async"を使用している。
7. 画面の下部にある画像はloading="lazy"を使用している。
8. AVIFまたはWebPを配信し、JPEGはフォールバックとしてのみ使用する。
9. srcsetとsizesが表示に適したファイルを配信している。
10. 画像がエッジキャッシュを備えたCDNから配信されている。

実際の注意点

ラボの数値はフィールドの数値ではありません。私のクリーンアップはLighthouseでは完璧に見えましたが、実際には不均一に変動しました。なぜなら、実際のユーザーは制限された4G、ミッドレンジのAndroid、混雑したWi-Fiを使用しているからです。ここに記載されているすべての修正を適用した後、勝利を宣言する前に、PageSpeed Insightsのフィールドデータをフル28日間の期間で監視してください。CWVはシミュレーターが予測するものに基づいてではなく、実際のユーザーが経験するものに基づいてスコアリングされます。

よくある質問

画像が最も影響を与えるCore Web Vitalsメトリクスはどれですか？

LCPです。Largest Contentful Paint要素は通常ヒーロー画像であり、そのファイルサイズとロード順序がこのメトリクスを支配します。次にCLSが続き（寸法を持たない画像によるスペースの予約）、そしてINPが3番目に来ます（遅い画像デコードがメインスレッドをブロックするため）。ヒーロー画像を縮小しプリロードすることが、他の単一の修正点よりもLCPを大きく改善させます。

遅延読み込みとプリロードの両方が必要ですか？

プリロードが必要なのは1つの画像だけです—それはLCPのヒーローであり、積極的にロードされる必要があります。画面の下部にあるすべての画像にはloading="lazy"を使用し、帯域幅でヒーローと競合させないようにします。遅延読み込みされた画像をプリロードすることは矛盾しており、バイトを無駄にします。ヒーローをプリロードし、残りを遅延読み込みしてください。

Core Web Vitalsが私の画像修正